0251 / 590 837 15
info@a-coding-project.de
;

Code Guidlines für ContentLion

Coding Guidlines sind bestimmte Programmierrichtlinien, an die sich die Programmierer eines Projektes halten sollten. Da wir ab bald auch aktiv zu mehreren bei ContentLion programmieren, ist es Zeit sich einmal zusammen solche Guidlines zu überlegen.

Warum Coding Guidlines?

Unser Quellcode sollte überall gleich aussehen, so dass man ohne Probleme seine Sachen wiedererkennt. Außerdem sind in den Coding Guidlines bestimmte Regeln festgelegt, die dabei helfen Fehler zu vermeiden und evtl. Performance herauszuholen.

ContentLion

Natürlich werde ich nicht alleine bestimmen, wie programmiert werden soll. Ich würde mich am Mittwoch gerne in unserem Live-Meeting darüber unterhalten und auch Regeln festlegen. Off Topic: In Kürze startet hier der neue Countdown, diese Seite müsst ihr wieder benutzen, wenn’s am Mittwoch um 20:30 losgeht!

Vorlage

Ich habe mir bereits einige Gedanken zum Thema gemacht, die ich euch vorab schon zeigen möchte. So könnt ihr schon mal eine Meinung darüber bilden und weitere Regeln ausdenken oder Regeln überarbeiten / löschen. Wenn ihr die Regeln nicht verstanden habt, könnt ihr das jetzt schon melden, ansonsten merkt euch die Vorschläge / Kritik bis Mittwoch 😉

Alle Namen auf Englisch

Alle Namen müssen sprechend sein

Der PHP –Code muss ohne Warnungen funktionieren

Klassennamen werden großgeschrieben

Funktionen und Eigenschaften im Camel-Casing (Beispiel: readField)

Private Variablen (in Funktionen) werden kleingeschrieben

Konstanten werden komplett großgeschrieben

Unterstriche in Namen sind verboten

Einrückung erfolgt mit Zwei Leerzeichen

Funktionen ab 3 Zeilen (Inhalt) müssen am Anfang eine $res Variable haben und diese zurückliefern

Funktionen über 15 Zeilen müssen in Unterfunktionen aufgeteilt werden

Klassenvariablen müssen als protected deklariert werden

Zugriff auf Klassenvariablen wenn nötig über Getter- und Setter Methoden (getVariable)

Funktionen müssen mit public , private oder protected deklariert werden

Objekte als Funktionsparameter müssen mit Type-Hints angegeben werden

Maximal 3 Parameter pro Funktion (ansonsten müssen neue Objekte eingesetzt werden)

Klassen gehören in eigene Dateien

Html-Code sollte je nach Länge in eigene Templates ausgelagert werden (ansonsten nach Eva-Prinzip)

Es sollen immer nur doppelte Anführungszeichen eingesetzt werden

Für PHP-Tags wird <?PHP genommen -> alle PHP Tags müssen geschlossen werden

Klammersetung

Erfolgt nach dem folgenden Muster:

if(true) {

}

else{

}

|| statt or und && statt and

Keine Übergabe von Boolean-Parametern an Funktionen, stattdessen zwei verschiedene Funktionen benutzen

Keine Kommentare im Quellcode

Der Quellcode sollte auch ohne Kommentare gut lesbar sein. Wenn die Funktion nicht klar wird, sollten Konstanen benutzt werden bzw. die Funktion sollte unterteilt werden.

Quellcode-Doku geschieht in externen Dokumenten.

Code soll nicht auskommentiert werden, da dieser sowieso im SVN vorhanden ist.

Maximal 80 Zeichen pro Zeile

Pro Befehl nur eine Zeile