Skip to content

Coding Standards By Initial Team

Morpheus edited this page Jul 14, 2021 · 7 revisions

During our project we followed the XP Practice "Coding Standards" to uniform our code and follow good practices. Even though we can not force you to follow them, we still recommend you to keep them in mind to enforce consistency throughout the entire code. Trust us, this will make your life easier in the long run 🐧

  1. Methodenaufbau:
    Erste Zeile: Methodennamen mit Parameter
    -> Dabei immer Präfix [a | an] für Parameter wie zB. aString, anObject
    2 - n.Zeile : Kommentar
    n+1. Zeile: Zeile leerlassen
    n+2. Zeile: lokale Variablen
    n+3. Zeile: Methodencode

  2. Wenn es basicAccessor und accessor gibt, muss accessor kommentiert werden.

  3. Letzte Zeile einer Funktion mit keinem Punkt.

  4. In Kommentaren: Klassen werden großgeschrieben.

  5. Konstruktor auf Klassenseite setzt nur die Parameter, welche übergeben werden.

  6. Initialize der Variablen stets in der initialize-Methode der Klasse (möglichst lazy init vermeiden).

  7. Hardgecodede Daten als Konstanten auf Klassenseite / Klassenmethoden

  8. Konstruktoren nicht mit with:with:with:... sondern havingString: readingFromFile: etc

  9. Konstruktoren stets mit Präfix new

  10. Bei Cascades folgender Aufbau (Methoden in extra Zeilen und eins eingerückt):
    objekt
       methode1;
       methode2

  11. Bei Blöcken keine Leerzeichen zwischen Blockinhalt und Blockklammern.

  12. Format bei Ein-Statement-Blöcken, sofern Codezeile nicht zu lang:
    someCode: [statement]
    Format bei Blöcken mit mehreren Statements:
    someCode: [
      statement1.
      ...statementN]

  13. In Schleifen haben Variablen auch die Vorsilbe [a | an] (wie in Parametern)
    Bsp: self submorphs do: [:aMorph | ...]
    und nicht self submorphs do: [:morph | ...]
    Ausnahme bilden Variablen, die keine Collection von Objekten sind, hier wird the verwendet
    Bsp: self doSomethingSelector ifNotNil: [:theSymbol | ...]

  14. Klammern bei Code über mehrere Zeilen wie folgt: (Smalltalk-style brackets)
    self submorphs do: [:aMorph |
        code]

  15. has<>, is<>-Methoden, die nicht direkt den Wert einer Instanzvariable wiedergeben in Category “testing”.

  16. Leerzeile zwischen super und eigentlichem Code:
    super initialize.

    code ...

  17. Leerzeile vorm Return

  18. Leerzeichen bei Punkten: 10 @ 10

Clone this wiki locally