✔ C# Aufbau von Code/ eines Programms
- Themenstarter NSR
- Beginndatum
NSR
Mitglied
Also ich bin noch dabei meinen 'eigenen Stil' zu suchen und das war ein grund den Thread zu erstellen.
Also bisher mach ichs so.
Ich pack die Variablen, den Konstruktor und die Methoden in eigene #regions.
Die Methoden teil ich noch in Events und in eigene Methoden (auch #regions).
Alles Kommentieren und fertig.
Eine frage, ist es gut (bin dabei zu überlegen, ob ich des mit rein nehmen soll)
am Ende von {} hinter die } ein kommentar zu schreiben, der angibt, wo die {} beginnt.
Beispiel
private void Methode_MachDies()
{
} //Methode_MachDies
jetzt habt ihr auch gesehen, wie ich meine Methoden benenne. Immer Methode_ .
Das mit den Kommentaren wenn ja dann auch bei #regions oder was anderes nehmen oder gar nichts?
#region - Variablen -
private void Methode_MachDies()
{
}
//--------------------------
#endregion //region - Variablen -
Also schreibt einfach eure gedanken und/oder eueren Stil hin, wenn ihr ihn teilen wollt.
Also bisher mach ichs so.
Ich pack die Variablen, den Konstruktor und die Methoden in eigene #regions.
Die Methoden teil ich noch in Events und in eigene Methoden (auch #regions).
Alles Kommentieren und fertig.
Eine frage, ist es gut (bin dabei zu überlegen, ob ich des mit rein nehmen soll)
am Ende von {} hinter die } ein kommentar zu schreiben, der angibt, wo die {} beginnt.
Beispiel
private void Methode_MachDies()
{
} //Methode_MachDies
jetzt habt ihr auch gesehen, wie ich meine Methoden benenne. Immer Methode_ .
Das mit den Kommentaren wenn ja dann auch bei #regions oder was anderes nehmen oder gar nichts?
#region - Variablen -
private void Methode_MachDies()
{
}
//--------------------------
#endregion //region - Variablen -
Also schreibt einfach eure gedanken und/oder eueren Stil hin, wenn ihr ihn teilen wollt.
Hi,
ich bin der Meinung das man auch alles irngdwie Übertreiben kann. Es ist zwar super schön und jeder weiß direkt was du damit "vorhast" aber ich denke, das es auch sehr mühsam ist, es zu flegen. Naja nun Gut. Jeder hat natürlich seine eigenen Vorstellung UND dem entsprechend seinen eigenen Stil. Aber ich denke, das es weniger auch "getan" hätte bzw. tun würde
Viele Grüße
ich bin der Meinung das man auch alles irngdwie Übertreiben kann. Es ist zwar super schön und jeder weiß direkt was du damit "vorhast" aber ich denke, das es auch sehr mühsam ist, es zu flegen. Naja nun Gut. Jeder hat natürlich seine eigenen Vorstellung UND dem entsprechend seinen eigenen Stil. Aber ich denke, das es weniger auch "getan" hätte bzw. tun würde
Viele Grüße
Die Kommentierung am Ende eines } würde ich mir sparen, die IDE hilft dir schon dabei den Anfang zu finden.
Man sollte außerdem nicht übermäßig große Funktionen schreiben.
Ansonsten kommentieren ich alle public und privaten Methoden mit Summary, param, return und exception (Ev. typeparam). (Bis auf die Ereignis Methoden)
Dazu noch alle Eigenschaften und wenns mir sinnvoll erscheint auch die privaten Felder.
Hinzu kommen noch Code Samples wenn andere meine Objekte ableiten müssen.
Und natürlich wichtig <see ref> wenn ich in der Beschreibung auf andere Objekte verweisen will.
#region verwende ich zum Beispiel wenn mehrer Methoden für eine Sache wichtig sind um diese zu "gruppieren" oder ich mehrere Ereignisse von einem Control/Objekt verwende.
Ich persönlich bin der Meinung man kann nicht genug kommentieren, es hilft einfach dritten (und dir selbst in paar Monaten) den Code zu verstehen.
Man sollte außerdem nicht übermäßig große Funktionen schreiben.
Ansonsten kommentieren ich alle public und privaten Methoden mit Summary, param, return und exception (Ev. typeparam). (Bis auf die Ereignis Methoden)
Dazu noch alle Eigenschaften und wenns mir sinnvoll erscheint auch die privaten Felder.
Hinzu kommen noch Code Samples wenn andere meine Objekte ableiten müssen.
Und natürlich wichtig <see ref> wenn ich in der Beschreibung auf andere Objekte verweisen will.
#region verwende ich zum Beispiel wenn mehrer Methoden für eine Sache wichtig sind um diese zu "gruppieren" oder ich mehrere Ereignisse von einem Control/Objekt verwende.
Ich persönlich bin der Meinung man kann nicht genug kommentieren, es hilft einfach dritten (und dir selbst in paar Monaten) den Code zu verstehen.
Alexander Schuc
crazy-weasel
Hi.
Wirf mal einen Blick auf:
Internal Coding Guidelines
Zu deiner aktuellen Handhabung:
Die Benennung deiner Methoden ist grauenhaft. Gewöhn dir das ab!
Das es eine Methode ist sollte alleine schon aus dem Namen des Members hervorgehen, und es ist einfach nur umständlich wenn du andauernd "Methode_" tippen müsstest. Auch wenn du IntelliSense verwendest.
Immer erstmal "Methode_" tippen, dann endlich einen Teil des wirklichen Namens und dann erst Tab zum Vervollständigen. Outsch!
Für Methoden solltest als Namen einfach Verben, oder Satz ähnliche Konstrukte verwenden die andeuten was die Methode macht.
Stell dir mal vor jede Methode in .net würde mit "Methode_" beginnen.
Kommentare hinter schließenden, geschwungenen Klammern sind überflüssig. Da du deinen Code hoffentlich ordentlich einrückst, und nicht zu lange Konstrukte verfasst ist das nicht notwendig. Ansonsten hilft die einerseits deine IDE beim Auffinden des Blocks, oder man verwendet AddIns welche die das noch besonders hervorheben. (z.b. CodeRush Express (gratis))
Du solltest dir übrigens angewöhnen deinen Code in englischer Sprache zu verfassen. Einerseits schauts geordneter aus, wenn in deinem Code kein Sprachmischmasch vorkommt, andererseits kanns irgendwann mal vielleicht praktisch sein, wenn jemand anderes deinen Code lesen muss.
Mh, ansonsten. Lesen was in meinem ersten Link steht. Dieser Guide ist schon ganz gut.
Zur Benennung von den einzelnen Konstrukten etc rate ich dir zu dieser Lektüre: Naming Guidelines
Ach, eines noch: "eigener Stil".
Den Code kannst du prägen durch die Art und Weise wie du Probleme angehst und sie löst, aber nicht in der Art und Weise wie du ihn formatierst. Spätestens in einem Team muss die Formattierung konsitent sein. Da kannst du nicht mit deinem eigenen Stil hervorstechen, das erschwert nur die Arbeit. Gewöhne dir also keine abartigen Macken an, so wie deine Benennung der Methoden.
lg, Alex
Wirf mal einen Blick auf:
Internal Coding Guidelines
Zu deiner aktuellen Handhabung:
Die Benennung deiner Methoden ist grauenhaft. Gewöhn dir das ab!
Das es eine Methode ist sollte alleine schon aus dem Namen des Members hervorgehen, und es ist einfach nur umständlich wenn du andauernd "Methode_" tippen müsstest. Auch wenn du IntelliSense verwendest.
Immer erstmal "Methode_" tippen, dann endlich einen Teil des wirklichen Namens und dann erst Tab zum Vervollständigen. Outsch!
Für Methoden solltest als Namen einfach Verben, oder Satz ähnliche Konstrukte verwenden die andeuten was die Methode macht.
Stell dir mal vor jede Methode in .net würde mit "Methode_" beginnen.
Kommentare hinter schließenden, geschwungenen Klammern sind überflüssig. Da du deinen Code hoffentlich ordentlich einrückst, und nicht zu lange Konstrukte verfasst ist das nicht notwendig. Ansonsten hilft die einerseits deine IDE beim Auffinden des Blocks, oder man verwendet AddIns welche die das noch besonders hervorheben. (z.b. CodeRush Express (gratis))
Du solltest dir übrigens angewöhnen deinen Code in englischer Sprache zu verfassen. Einerseits schauts geordneter aus, wenn in deinem Code kein Sprachmischmasch vorkommt, andererseits kanns irgendwann mal vielleicht praktisch sein, wenn jemand anderes deinen Code lesen muss.
Mh, ansonsten. Lesen was in meinem ersten Link steht. Dieser Guide ist schon ganz gut.
Zur Benennung von den einzelnen Konstrukten etc rate ich dir zu dieser Lektüre: Naming Guidelines
Ach, eines noch: "eigener Stil".
Den Code kannst du prägen durch die Art und Weise wie du Probleme angehst und sie löst, aber nicht in der Art und Weise wie du ihn formatierst. Spätestens in einem Team muss die Formattierung konsitent sein. Da kannst du nicht mit deinem eigenen Stil hervorstechen, das erschwert nur die Arbeit. Gewöhne dir also keine abartigen Macken an, so wie deine Benennung der Methoden.
lg, Alex
NSR
Mitglied
Sorry hab schon lange nich mehr reingeschaut.
Des Thema isch nen bissle ausm ruder gelaufn. -> Das Thema wurde nen bissle verfehlt.
Ich meinte mit dem thema, dass hier wer möchte seine Programmierstil vorstellen kann, un dass sich andere, wenn man was findet, des einem Gefällt des übernehmen können.
Des Thema isch nen bissle ausm ruder gelaufn. -> Das Thema wurde nen bissle verfehlt.
Ich meinte mit dem thema, dass hier wer möchte seine Programmierstil vorstellen kann, un dass sich andere, wenn man was findet, des einem Gefällt des übernehmen können.
kuddeldaddeldu
Erfahrenes Mitglied
Hi,
Das, was Du anscheinend unter Programmierstil verstehst, ist aber etwas, was man sich gar nicht erst angewöhnen sollte, wie Alex schon so treffend festgestellt hat:
Und poste doch bitte in hochdeutsch unter Berücksichtigung der Rechtschreibung, wie es in der Netiquette gewünscht wird. Das erleichtert Benutzern aus anderen Teilen Deutschlands das Lesen. Vielen Dank.
LG
Das, was Du anscheinend unter Programmierstil verstehst, ist aber etwas, was man sich gar nicht erst angewöhnen sollte, wie Alex schon so treffend festgestellt hat:
Und poste doch bitte in hochdeutsch unter Berücksichtigung der Rechtschreibung, wie es in der Netiquette gewünscht wird. Das erleichtert Benutzern aus anderen Teilen Deutschlands das Lesen. Vielen Dank.
LG
NSR
Mitglied
Ich vermute du meinst diesen Abschnitt. Gut, werde die Netiquetten besser/mehr beachten.
Neue Beiträge
-
-
-
-
Python Formatter-Dilemma = Python-Dilemma?
- Letzte: jemand anders
