Konventionen

[hOk]

Hi Leute,

ich weiß Konventionen können grauenhaft sein,
doch wenn Sie als nicht starre Leitlinie gesehen
werden können Sie einem richtig helfen.

Konvention
1. Übereinkunft, Abkommen
2. Regeln des Umgangs, des sozialen Verhaltens
die für die Gesellschaft als Verhaltensnorm gelten.

Meine momentanen Konventionen:

• Benennung
• Bezeichner-Präfixe um den Typ oder die Klasse anzugeben, (z.B.:arrUser)
• oder Bezeichner-Postfixe aus dem selben Grund (z.B.: user_arr), aber nicht mischen
• Aussagekräftige Bezeichner (z.B.: hashPasswordByUser = { strPeter:'qwertz'})
• Klassen-Bezeichner-Suffix: "Class" (z.B. AutoClass)
• Klassen groß schreiben (z.B.: WindowClass)
• Wörter in Bezeichnern mit Großschreibung trennen (z.B.: hashPasswordByUser)
• Magische Zahlen/Strings durch symbolische Konstanten ersetzen (z.B.: 2*Math.PI*r statt 2*3.14*r)
• Zusätzliches Praefix für Funktionsparameter (z.B. p wie in pStrName)
• Komplexe boolesche Ausdrücke benennen, z.B. durch Einsatz einer Methode (z.B.: isValidUser())
• Wenn Methoden zu einem bestimmten Zeitpunkt ausgeführt werden, sollte sich dies im Namen der Methode wiederspiegeln (z.B.: onLogin)
• Verwende Präfixe (is, has) für Methoden und Eigenschaften die Wahrheitswerte (true, false) liefern (z.B. isEmpty, hasChildNodes()).
• Verwende plural für die Bezeichner von Listen[powered by Klitze]
• Konstanten großschreiben (MX_CONSTANT = 12)
• Imperative Form für Methoden-Namen (getValue, readFile)
• Events sollen so heissen wie ihr Auslöser (und nicht wie das, was ausgelöst wird)
  
  Kommentare
• Programmblöcke in Absätze mit // teilen
• Schreibe, wenn möglich, Kommentare im imperativ(Befehlsform) (z.B.: read Username)[inspired by wolter...;-)]
• Vermeide Kommentare, wenn der Code selbsterklärend ist.
  
  Struktur
• Menge der Funktionparameter klein halten (eher Klassenvariablen benutzen)
• Eine ander Möglichkeit zur Reduzierung von Funktionsparametern ist die Benutzung von ParameterObjekten. (wie z.B. bei den onChange-Handlern der FUI-Komponenten)
• Anzahl lokaler und globaler Variablen kleinhalten (eher Klassenvariablen benutzen)
• Verschachtelungen minimieren
• exit-Bedingungen sofort ausführen (z.B. if(bedingung) return 1; anstatt if(bedingung){result=1} else {result=2}; return result)
• Den Bedingtoperater(?: ) für Zuweisungen verwenden, und nicht für Verzweigungen mißbrauchen
• Prüfe die übergebenen Parameter in öffentlichen Methoden.
• Vermeide Seiteneffekte bei Funktionen, die ein Ergebnis liefern.
• Handler werden nie direkt definiert, sondern immer zugewiesen. (nie onHandler = function(){}, immer onHandler = myFunc)
• Bei semantischer Differenz zwischen Methoden-Name und Teilen aus dem Methoden-Rumpf, Methode extrahieren (-> selbstdokumentierender Code)
• Bei semantischer Differenz zwischen Klassen-Name und Methode, Klasse extrahieren (-> selbstdokumentierender Code)
  
  Klassen
• return in der Konstruktorfunktion, wenn 'NO_INIT' übergeben wird, um die unnötige und störende Initialisierung bei new-Vererbung zu vermeiden[Inspired by bokel...;-)]
• Alle Klassen-Variablen sollten im Konstruktor initialisiert werden
• Kindklassen sollen die Funktionalität der Elternklassen erweitern ohne die Vorbedingungen der Elternklassen zu vernichten d.h. überall wo die Elternklasse benutzt wird, soll ohne Probleme die Kindklasse eingesetzbar sein.
  
  Allgemeines
• Lange Zeilen vermeiden
• Kein Sprachmischmasch entweder deutsch oder englisch
• Keinen Code doppelt schreiben, lieber Methode oder Klasse extrahieren
• ca. max. 16 Methoden pro Klasse, sofern möglich
• ca. max. 16 Zeilen pro Methode, sofern möglich
• innherhalb von ca. 10 Sekunden sollte erkennbar sein was eine Methode macht
• KISS, Keep it Simple and Stupid, vermeide EierlegendeWollmich-Säue[flory]
• Lieber orthodox als unkonventionell programmieren
  
  Optimierung
• Wenn es um hochoptimierten Code geht vergiss alle Regeln, speichere möglichst viel lokal, verwende kurze Bezeichner, verwende inline-Includes statt Funktionen.
• Die Optimierungen sollten sofern möglichst am Ende des Projektes geschehen. Bedenke, dass oftmals 10% des Codes 90% der Performance schlucken, also nicht alles optimieren, sondern nur diese Kernbereiche (Profiling). Das spart einerseits Arbeit und andererseits bleibt der Code lesbar.
  
  Tricks
• Verwende __resolve um Tippfehler bei Eigenschaften und Methoden automatisch zu erkennen
  

Was verwendet ihr für Konventionen?
netten Gruß, Holger

[bokel]

Prae- und Postfixe (bis auf Class für Klassen) benutze ich nicht. Ich finde sie nicht besonders schön. Wenn deine Methoden übersichtlich sind, dann kann man meist auch so sehr schnell erkennen, um welche Art von Objekt es sich handelt.

Bei public Routinen, die also auch von anderen Programmierern benutzt werden, prüfe ich die Parameter auf Gültigkeit.

Konstruktoren verlasse ich sofort mit return, wenn nur eine Vererbung hergestellt werden soll.

mfg r.

[hOk]

@bokel
Das mit den "fehlenden" Präfixen musste ich auch
beim Lesen der Preloader-Class feststellen und es
hat mich schon ein bischen genervt, weil ich dadurch
fast doppelt so oft scrollen musste. Ansonsten empfinde
ich die Klasse als absolutes Parade-Beispiel für les-, wart-
und erweiterbaren Code.
Auch schön zu sehen war der Einfluss vom Fowler, der
mich ja auch super beeinflusst hat.

Den return im Konstruktor erspare ich mir in dem ich diesen
leer lasse und init-Methoden verwende, geschmacksache.

Und da das Thema doch uns alle angeht hoffe ich noch
auf weitere Anregungen, Ergänzungen und Kommentare.

netten Gruß, Holger

[bokel]

Hi Holger

Geschrieben von hOk
Das mit den "fehlenden" Präfixen musste ich auch
beim Lesen der Preloader-Class feststellen und es
hat mich schon ein bischen genervt, weil ich dadurch
fast doppelt so oft scrollen musste.

Schuldig im Sinne der Anklage
Mir gefällt es einfach nicht, es macht für mich den Code weniger lesbar, genauso wie komisch abgekürzte Variablennamen

Den return im Konstruktor erspare ich mir in dem ich diesen leer lasse und init-Methoden verwende, geschmacksache.

Wenn du alle Eigenschaften im Konstruktor initialisieren willst, geht das aber nicht, oder ?



Ich habe noch eine MetaKonvention: Ich benutze meine Konventionen konsequent.

mfg r.

[Madokan]

Moin Jungs,

Konventionen sind eine "gute" Sache. Meist jedoch auf Teams oder einzelne Developer beschränkt. Eine Art-universal Konvention wird wohl immer ein Traum einiger weniger bleiben. Der eigene Stil setzt sich bei der Umsetzung doch immer wieder durch.

Aber eine Art Sammlung von Konventionen kann sicher nicht schaden.

Liebe Grüsse
Matze K.

[hOk]

Geschrieben von bokel
Wenn du alle Eigenschaften im Konstruktor initialisieren willst, geht das aber nicht, oder ?

Stimmt, initialisieren tue ich Sie aber trotzdem alle auf einmal
und zwar in der init-Methode, ist schwierig zu merken

grüße, Holger

[wolter]

hmmm,

warum verwendest du so wenig lokale variablen wie möglich? bis jetzt hab ich eigentlich immer versucht, soviele verwendete variablen wie möglich lokal anzulegen (ausser sie machen einen sinn als eigenschaft).

und mir fehlt noch der hinweis, dass kommentare immer im imperativ geschrieben werden sollten (macht sie besser, lesbar, bringt es mehr auf den punkt und ist kürzer). programmcode dessen kommentare länger und umständlicher zu lesen sind als der code selber, finde ich nämlich schrecklich.

gruss,

sascha.

[bokel]

Geschrieben von wolter
kommentare

Hehe hok, sagst du es ihm oder ich ?



mfg r.

[wolter]

ihr könnt mich doch nicht unwissend in den tag gehen lassen?!

gruss,

sascha.

[bokel]

In einem sauber und lesbar aufgebauten Programm sind Kommentare meistens überflüssig oder weisen auf schlechten Code hin.
Wenn du einen Kommentar brauchst, um zu erklären, was ein Codeblock macht, dann mach eine Funktion draus und gib ihm einen sprechenden Namen.

Diesen und viele andere wertvolle Tips findest du in Fowlers Buch über Refactoring. Dieses Buch wird dich verändern.

mfg r.

[wolter]

klar hast du recht, aber anspruch und wirklichkeit... aber das buch ist nun bestellt. so oft wie ihr das erwähnt, will ich nicht weiter "dumm" durch die welt laufen .

gruss,

sascha.

[kelor]

In einem sauber und lesbar aufgebauten Programm sind Kommentare meistens überflüssig oder weisen auf schlechten Code hin.
Wenn du einen Kommentar brauchst, um zu erklären, was ein Codeblock macht, dann mach eine Funktion draus und gib ihm einen sprechenden Namen.

sorry ralf... aber das iss hahnebüschend....

saubere beschreibende kommentarblöcke sind mehr als nur legitim, sie sind sogar zwingend erforderlich.

diese weisheit da oben hatte dazu geführt, dass millionen von programmierer ein w2k problem hatten, weil code nirgendwo kommentiert war und man in den alten, komplexen programmblöcken die zeitbrücken nicht mehr finden konnte.

greetz

kelor

[bokel]

Schön dass du in den Thread einsteigst Kelor, denn du bist ja sozusagen der Hohepriester des unlesbaren Codes.

Wie man in diesem Thread bewundern durfte, brauchst du für ein absolut simples Stück Code mehrere Seiten Kommentare, um zu erklären, was da passiert.

Das Problem bei dieser Arbeitsweise ist, dass Code und Kommentare die Tendenz haben, sich mit der Zeit voneinander zu entfernen. Und dann bedeutet viel Kommentar auch viele Möglichkeiten für Fehler.

Wenn du im Gegensatz dazu sprechende Namen für deine Bezeichner benutzt, dann kann das gar nicht passieren. Der Kommentar ist praktisch schon im Code enthalten und entwickelt sich dadurch automatisch mit.

mfg r.

[bokel]

Geschrieben von wolter
klar hast du recht, aber anspruch und wirklichkeit

Anspruch und Wirklichkeit klaffen bei der Kommentierung eher noch weiter auseinander, oder ?

Ich bin gespannt, was du von dem Buch hälst.

mfg r.

[wolter]

yep, das buch interessiert mich wirklich sehr. und glücklicherweise hab ich gleich nach der englischen variante ausschau gehalten. die übersetzung scheint ja eine katastrophe zu sein... jetzt hoffe ich nur noch, dass das buch nochbis morgen kommt, denn am kommenden wochenende hab ich ausnahmsweise mal ein wenig zeit .

gruss,

sascha.