Ich will aber...ordentlich Programmieren: Konventionen

frauenPower

frauenPower

Aktives Mitglied
Thread Starter
Dabei seit
21.06.2011
Beiträge
287
Reaktionspunkte
75
Hallo in die Runde,

damit mich auch andere Programmierer verstehen, versuche ich mich an die allgemeinen Konventionen zu halten.

Objective-C ist hier angesprochen.

Es wäre schön, wenn Ihr uns/mir in diesem Thread weitere Konventionen benennen würdet.

Liebe Grüße
Karin

Konventionen
  • Klassennamen Beginnen immer mit einem Großbuchstaben. CamelCase. MeineKlasse
  • Instanzenvariablen Beginnen immer mit einem Kleinbuchstaben. CamelCase. ichInstanzenvariable
  • Methodennamen Beginnen mit einem Kleinbuchstaben. CamelCase. meineCooleMethode
  • Konstanten Bestehen nur aus Großbuchstaben. Mehrere Worte werden durch Unterstrich getrennt. MEINE_KONSTANTE
  • Statements Nur ein Statement pro Zeile.
  • Dokumentieren Im besten Fall: 1 Zeile Doku für 1 Zeile Code.
  • Abstraktionsbarriere für Instanzenvariablen Getter und Setter verwenden.
 
Zuletzt bearbeitet:
In welcher Sprache?

Edit: Ah müsste dann deinem anderen Thread folgend Objective-C sein.

Ich kenne Programmierer, die so "kurz" programmieren möchten, wie irgend möglich. Dahingehend denke ich, dass es für die Lesbbarkeit wichtig ist nur ein Statement pro Zeile zu haben.

Bei Vergleichen if var == XYZ und nicht if XYZ == var

Anständig dokumentieren (theoretisch eine Zeile Doku für jede Zeile Code). Des Weitern ggf eigene Konventionen einführen. Also z.B. Präfixe für Variablentypen.

Getter und Setter für die Kappselung des Zugriffs aus Objektvariablen verwenden.

DAO Schicht für Datenzugriff realisieren.

Und sicher eine ganze Menge mehr. :)


Viele Grüße
 
Zuletzt bearbeitet:
Zitieren
  • Gefällt mir
Reaktionen: SchaSche, frauenPower und wegus
Du bist wahnsinnig...

Nun ja, so hab ich es mal gelernt:

Konstanten bestehen nur aus Grossbuchstaben. Mehrere Worte werden durch Unterstrich getrennt.

Viele Gruesse
Andreas

Spaeter mehr, bin in einem Meeting.
 
Die Konventionen gibt es nicht. Es gibt sprachabhängige und es gibt auch Firmenabhängige Konventionen.
 
Wahnsinn? Was ist das :hamma:

Nee, nee gehört auch so nebenbei zu meinem Lernen und deshalb hoffe ich hier auf Input, damit ich nicht auf Seite 12431 wieder eine neue Konvention mitgeteilt bekomme. :)

Liebe Grüße
Karin
 
@wegus
Deshalb habe ich jetzt auch den Hinweis auf Objective-C eingefügt und wenn ich mich ein wenig an dem "Standard" orientiere kann es so falsch ja nicht sein.

Mein Code sieht schrecklich aus und mit solchen "Konventionen" wird er dann doch besser lesbar. Warum also das Rad neu erfinden?

Liebe Grüße
Karin
 
Wenn möglich alles in das jeweilige Design pattern einbetten. Und dadurch strucktur schaffen. (nicht over engineeren!)

Code metriken beachten, gegebenenfalls refactoren wärend dem codieren.

Sprechende Bezeichner und Kopfkommentare sollten klar sein.

Tests paaralel zum codieren ziehen.
dh: Du schreibst eine neue Klasse paarallel ziehst du deinen classTest hoch. In dem moment wo du die Klasse und den Test ins git pushst ist eine komplette Pfadabdeckung vorhanden.
 
@felix88
Deine Vorschläge werden auch eingebaut. Gib mir dafür ein paar Tage Zeit. Muss erstmal verstehen, was Du da alles ansprichst.

Danke Dir schon jetzt dafür und es geht nichts verloren!

Liebe Grüße
Karin
 
Danke Dir. Gehe ich dann mal durch.
Ist auch ein Fall für die Linkliste und wird eingefügt.

Liebe Grüße
Karin
 
Scott Stevenson hat mal eine kompakte Zusammenfassung der Naming Guides erstellt.
Cocoa Style for Objective-C

Die werfe ich heute noch unseren Neulingen als aller erstes an den Kopf.
 
Ebenfalls eine schöne Zusammenstellung.

Wunderbar.

Danke
Karin

P.S.: Auch ein Fall für die Linkliste :)
 
Mann, Du hälst mich auf positiven Trab!

Ergänze ich noch heute, hab ja Zeit genug. Sehr viele GBytes zum Download.
Dein Linktipp im Nachbarthread war Gold wert.

Liebe Grüße
Karin
 
Manche werden mich schlagen, aber ich werfe "Clean Code" in den Raum. Das fasst so ziemlich alles zusammen, was sauberes Programmieren angeht.

d1zZy schrieb:
Anständig dokumentieren (theoretisch eine Zeile Doku für jede Zeile Code).
Zum Vergrößern anklicken....
Naja, praktisch sollten Kommentare sinnvoll sein. Nicht die Menge ist entscheidend sondern, der Nutzen. Ich sehe zb immer wieder Kommentare an Methoden, die den Namen in etwas blumigeren Worten wiederholen. Das kann man sich auch sparen. Wichtig sind dann eher (Pre-/Post-)Conditions und besondere Vorkommnisse. Und wenn ein Codeblock besonders komplex ist, sollte man ausgiebig kommentieren. Der beste Code ist aber (gerade im Sinne von Clean Code) selbsterklärend und muss nicht kommentiert werden. Da stören Kommentare eher den Lesefluss. Ach: Methodennamen (Messagenamen) und Namen von Variablen sind sinnvoll zu wählen. Objective-C erlaubt auch Namen, die länger als 2 Zeichen sind *grins*.
 
PS. Nochmal Stichwort Variablennamen: Benenne eine Variable nicht nach ihrem Typ sondern gibt ihr einen für die Instanz des Typs einen sinnvollen Namen.

Bsp:
Code: 
Person person; // schlecht
Person p; // ganz schlecht :P

Person carsten; // richtig ;)
 
_ebm_ schrieb:
Manche werden mich schlagen, aber ich werfe "Clean Code" in den Raum. Das fasst so ziemlich alles zusammen, was sauberes Programmieren angeht.
Zum Vergrößern anklicken....
Warum sollte Dich jemand deswegen schlagen. Ich dachte darüber nach, ob ich das Buch empfehlen soll, aber dann dass einfach (insgesamt) too-much ist.

_ebm_ schrieb:
Naja, praktisch sollten Kommentare sinnvoll sein. Nicht die Menge ist entscheidend sondern, der Nutzen. Ich sehe zb immer wieder Kommentare an Methoden, die den Namen in etwas blumigeren Worten wiederholen. Das kann man sich auch sparen. Wichtig sind dann eher (Pre-/Post-)Conditions und besondere Vorkommnisse. Und wenn ein Codeblock besonders komplex ist, sollte man ausgiebig kommentieren. Der beste Code ist aber (gerade im Sinne von Clean Code) selbsterklärend und muss nicht kommentiert werden. Da stören Kommentare eher den Lesefluss.
Zum Vergrößern anklicken....
Richtig. Viel Kommentare heisst nicht unbedingt gut kommentiert zu haben.
 
Zuletzt bearbeitet:
iCode schrieb:
Warum sollte Dich jemand deswegen schlagen. Ich dachte darüber nach, ob ich das Buch empfehlen soll, aber dann dass einfach (insgesamt) too-much ist.
Zum Vergrößern anklicken....

Naja, in einer der letzen Firmen, für die ich gearbeitet hab kam Clean Code zur Sprache und alle haben gejammert. Ich finde das ja auch übertrieben, was die CCD da "empfiehlt". (Jede Methode läßt sich auseinanderbrechen, am Besten je Ausdruck eine Methode...). Aber es sind gute Richtlinien, die den Code insgesamt auch lesbarer machen.
 
_ebm_ schrieb:
Naja, in einer der letzen Firmen, für die ich gearbeitet hab kam Clean Code zur Sprache und alle haben gejammert. Ich finde das ja auch übertrieben, was die CCD da "empfiehlt". (Jede Methode läßt sich auseinanderbrechen, am Besten je Ausdruck eine Methode...).
Zum Vergrößern anklicken....
Trägst Du etwa kein buntes Bändchen? ;)

Man kann es halt treiben, man kann es aber auch übertreiben. Man sollte das einfach pragmatisch und nicht dogmatisch anwenden.

_ebm_ schrieb:
Aber es sind gute Richtlinien, die den Code insgesamt auch lesbarer machen.
Zum Vergrößern anklicken....
Genau, und die Wartung erleichtern.
 
Zurück
Oben Unten