Coding Standards und Best Practices

  • Heyho,
    ich weiß, dass wird für viele ein alter Hut sein, aber ich denke, für Neulinge ist das ein interessantes Thema.
    Deshalb hier mal einige gute Seiten, zu den Themen, mit dem Wichtigsten rausgepickt. Vielleicht ist auch was für die Weisen unter euch noch was dabei.


    Eins vorweg: OOP bedeutet hier immer ObjektOrientierte Programmierung. Ich bin nur zu faul, das auch auszuschreiben


    Coding Standards
    Die Seite: Pear PHP Coding Standards. Allerdings etwas veraltet, deshalb hier die wichtigsten und universalen Punkte zusammen gefasst:

    • Kontrollstrukturen

      • Ein Leerzeichen vor der öffnenden und nach der schließenden Klammer
      • Immer die geschweiften Klammern verwenden, auch wenn optional
      • Wenn die Bedingungen zu lang werden (>80 Zeichen in der Zeile) kann vor den Vergleichsoperatoren umgebrochen werden, diese werden dann eingerückt (siehe Bsp., danke cotton)
      • Wenn man sich nicht sicher ist, ob == als Vergleich reicht (die PHP Dok. hilft), immer === verwenden



    • Funktionen

      • Funktionsnamen sind beschreibend, erster Buchstabe klein (Präfix zählt nicht), jedes "neue" Wort groß
      • Vor die Beschreibung sollte der Paketname gesetzt werden (klein) um Kollisionen mit anderen Funktionsnamen zu vermeiden
      • Bei der Definition soll der Original K&R Einrückungsstil verwendet werden (siehe Bsp.; ich persönlich bevorzuge aber ein einfaches Leerzeichen vor der öffnenden geschweiften Klammer)
      • Bei Aufrufen kein Leerzeichen nach Funktionsnamen, der öffnenden Runden Klammer und dem letzten Parameter
      • Leerzeichen nach Kommas zur Parametertrennung und der schließenden runden Klammer



    • Kommentare

      • Es sollte der C-Stil (// und /* */) anstatt dem Perl-Stil (#) verwendet werden
      • Blockkommentare werden eingerückt
      • Erste Zeile ist ein /**, bei den weiteren Zeilen ist ein Stern direkt unter dem ersten Stern der ersten Kommentarzeile zu setzen, mit einem Leerzeichen danach
      • Letzte Zeile ist der schließende */ Tag, mit der beschriebenen Instanz in der nächsten Zeile, ohne Leerzeile
      • Genaue Definitionen von Blockkommentaren in der oben verlinkten Dokumentation



    • OOP

      • Klassennamen beginnen mit Großbuchstaben, sowie Großbuchstaben bei jedem weiteren neuen Wort
      • Unterstriche werden nur verwendet, um die Klassenhierarchie auch in den Namen wiederzuspiegeln
      • Bei OOP werden private Funktionen (nicht protected) mit Unterstrich am Anfang deklariert
      • Die öffnende geschweifte Klammer soll in einer eigenen Zeile stehen
      • Es werden keine Klassen mit include/require oder _once eingebunden, stattdessen __autoload() oder eine personalisierte Version verwenden



    • Sonstiges

      • Konstanten werden immer komplett GROSS geschrieben, außer true, false, null, diese IMMER klein!
      • Einrücken mit 4 Leerzeichen, keine Tabulatoren
      • Zeilenlänge von um die 80 Zeichen (75-85 wird angegeben)
      • Eingebunden wird immer mit den _once Funktionen, welche kommt auf die Wichtigkeit des einzubindenden Codes an
      • Beispiel URLs sind example.com, .net oder .org
      • Es sollte für PHP Blöcke IMMER <?php ?> verwendet werden, nie Kurzformen
      • Zeilen sollten nur als LF erstellt werden, keine Mac CR oder Windows CRLF
      • Es wird in der Doc empfohlen, ASCII mit ISO-8859-1 zu verwenden, aber ANSI mit UTF-8 ohne BOM geht heute eigentlich auch und erlaubt auch mehr Zeichen in evtl. HTML Bereichen.



    Best Practices
    Hier habe ich eigentlich nicht wirklich viel zu sagen, im Grunde gibts nur zwei Links, ich hoffe, sie helfen trotzdem

    • Für die Entscheidung bei gewissen Codesnippets hilft diese Seite: The PHP Benchmark
    • Bei großen Projekten kann auch die Ungarische Notation von Variablen helfen (Apps Hungarian): Apps Hungarian
    • Zudem empfiehlt es sich, sich für wirklich große Sachen mit OOP vertraut zu machen, kann einem bei Benutzerverwaltung/Gästebucheintragen/allem mit mehreren Instanzen viel Arbeit abnehmen


    Ich hoffe, ich kann einigen hier den Weg zu sauberem Code von Anfang an weiter helfen, und auch den erfahrenen Jungs noch ein paar Tricks näher bringen (ich habe zB nicht gewusst, dass es SO große Unterschiede bei Schleifen geben kann).
    Wenn irgendetwas bei jemandem direkt Augenkrebs auslöst, bitte melden, genauso, wenn man noch weitere Tipps hat!


    Und wenn man nun stolz seinen suaberen Code im Forum präsentieren möchte (oder auch, wenn Fehler drin sind :D ), nutzt bitte gleich die Buttons über der Beitrags textarea!!! Die haben, Titel, welche angezeigt werden, wenn man mit der Maus drüberfährt, bitte nutzt die BB-Codes zur Codeformatierung!!!


    lauras : Vielleicht wäre es möglich, den Thread anzupinnen, ist, glaube ich, ein Thema, welches längerfristig wichtig ist, oder?

    Dieser Beitrag wurde bereits 5 Mal editiert, zuletzt von The Scout () aus folgendem Grund: Ein paar Hinweise eingefügt und Struktur der Einteilung (hoffentlich) verbessert

  • Da hab ich ja schon fast alles richtig gemacht.
    Nur das mit den Leerzeichen bei den Klammern - das find ich sowas von nervig :D
    Es liest sich einfach nicht schön, wenn man mit den Augen immer wieder über leere Stellen fliegt.


    Btw:
    ich weiß nicht, ob es allgemein so empfohlen wird - ich finde es aber übersichtlich:
    Bei zu großen If-Bedingungen

    PHP
    1. if(
    2. isset($_POST['langerName'])and !empty($_POST['langerName'])
    3. and isset($_POST['nochEinLangerName'])and !empty($_POST['nochEinLangerName'])
    4. and isset($abc)
    5. ){
    6. /*...*/
    7. }


    Man könnte alles in eine Zeile schreiben, was allerdings Augenkrebs verursacht.


    Ich hab mich dazu entschieden alle zusammengehörigen Bedingungen in eine Zeile zu schreiben, falls möglich.
    Das if und die öffnende Klammer stehen für sich alleine - so sieht man sie auf Anhieb.
    Die schließende Klammer und die öffnende geschweifte Klammer stehen auch für sich in einer Zeile.
    Das Prinzip kann/sollte man mMn überall verwenden.


    Wichtig für Angehende Programmierer: es ist nicht cool keine Klammern zu nutzen!
    Bestes Bsp war ja in den letzten Wochen der "goto fail"-Bug
    siehe: http://stackoverflow.com/quest…es-goto-fail-security-bug

  • cottton
    jo sieht gut aus (vll noch nen Leerzeichen vor das and^^) kenne es auch so, dass man das and (or , usw...) immer auf eine neue Zeile macht



    The Scout  
    vll noch sowas wie
    Klassen immer mit beginnenden Großbuchstaben
    === verwenden wenn es keinen Grund für == gibt
    elseif auseinander schreiben damits das gleiche wie in anderen Programmiersprachen ist

  • cottton : Danke, ich hab das mal übernommen. Steht zwar so direkt nicht in der Doc. allerdings wird es durch die begrenzte Zeilenlänge impliziert, deswegen habe ich es mit reingenommen und so weit standardisiert, wie möglich ^^


    Roland : Danke, das mit den Klassennamen habe ich wirklich vergessen, zu erwähnen.
    Und selten BRAUCHT man wirklich das ===, allerdings, schaut man sich die Benchmarkseite an, sieht man, es bringt einen geringfügigen Geschwindigkeitsvorteil. Aber ist auch möglich, das zu vernachlässigen, ich habs trotzdem reingenommen.
    elseif wird übrigens in der kompletten PHP und Standardisierungs Doc immer zusammen geschrieben ^^, da hat sich PHP ein wenig vom Rest distanziert. Aber für Leute, die von C oder C++ kommen, es macht keinen Unterschied ;)

  • Das Prüfen mit === kann Probleme machen.
    Wenn zB Werte über _GET kommen
    Bsp:
    $_GET['nummer'] kommt als 2 rein.
    Dann ist es allerdings eine "String-Zwei". Das kann viele Beginner verwirren.

    Aber ich sehe gerade - Du hast ja schon den Vergleich mit "2" drin stehen =)


    Du hast bei OOP ne class Net_Finger stehen, erzeugst dann aber n Obj von Foo_Bar oO?
    class Net_Finger is existiert ja nicht. Oder was seh ich da jetzt nich ? :D

  • Gute Sache - allerdings sind wirklich einige Sachen einfach Ansichtssache - mir persönlich erschließt sich z.B. der Sinn nicht, statt

    PHP
    1. function ganzTolleFunction() {
    2. ...
    3. }


    PHP
    1. function ganzTolleFunction()
    2. {
    3. ...
    4. }


    zu schreiben - da haben sich zwar bestimmt mal Leute was bei gedacht, aber wirklich Sinn macht es finde ich nicht, vor allem weil man es bei if & Co nicht macht.. Aber naja^^

  • Ja ich glaube, das ist genau deswegen: Bei if und Co Lücke zwischen Keyword und runder Klammer, sowie geschweifte in gleicher Zeile; bei Funktion runde Klammer direkt am Namen und geschweifte Klammer in neuer Zeile -> gute Unterscheidbarkeit. Aber ich mache es eigl. auch immer wie in deinem ersten Bsp :D

  • Ist denn das get in function gbgetComments nicht auch ein neues Wort und müsste folglich groß geschrieben werden? :whistling:


    ;) Denn gb stellt hierbei die Funktionsgruppe "Gästebuch" dar. Das heißt, "gb" als Präfix, danach der eigentliche Funktionsname nach Standardregeln...


    Du könntest dadurch nämlcih weitermachen, zB so:

    Und so weiter...

  • Ein bisschen das Grab aus schaufeln..
    Ich bevorzuge diese Version von Funktionsnamen
    Präfix darf ja klein Bleiben und erster Buchstabe ist Gros geschrieben. Außerdem hebt sich das Präfix klar vom Funktionsnamen ab. :)

    PHP
    1. function gb_SetEntry(){
    2. // Blubb
    3. }
    4. function gb_DeleteEntry(){
    5. // ...
    6. }