Konventionen

Smalltalk

Testing

Für alle Tests, die die Formatierung von OmegaPrint testen (Ausnahme ist z.B. TestUI), ist folgendes zu beachten:

• die Testklassen liegen im Paket OmegaPrint-Tests
• Testklassen werden nach dem Knoten benannt, den sie testen (z.B. TestFinalStatement oder TestExecutableCode), Ausnahmen für gewisse Funktionalität (z.B. TestComment für Kommentare) sollten eigentlich vermieden werden und die Tests in die Klassen ihrer Knoten gepackt werden
• Testklassen erben von OPTestEvaluator
• startSymbol gibt den Knoten zurück bei dem das Parsing in den Tests starten soll (Klassenname)
• Methodenkategorien richten sich nach den Unterregeln der Knoten:
  • startSymbol ist in der Kategorie constants
  • die Standard-Methodenkategorie ist base
  • für Spezialfälle (z.B. gefixte Bugs) kann man auch die Kategorie special cases nutzen
  • falls der Knoten case labels hat, richten sich die Kategorien danach (z.B. in der Klasse Expression, dort die Kategorien base, operandCascade, ...)
• der Methodenname ergibt sich durch die Namen der Kinderknoten des aktuell betrachteten Knoten:
  • alle Namen fangen mit test an
  • da die Knotennamen aber sehr lang sind, reduzieren wir sie auf den wichtigen Part (z.B. bindableIdentifier zu identifier)
  • alle Kindknoten werden durch with oder without geprefixt, je nachdem, ob sie in dem Eingabestring des Tests enthalten sind oder nicht
  • bei Kindknoten die mehrfach vorkommen können (+, *) benutzt man als Prefix withMultiple (und schreibt die Knotenart im Plural) oder withSingle
• der zu formatierende String (und vor allem der daraus resultierende CST) sollte möglichst simpel sein:
  • Leerzeichen nutzen wir nur, wenn sie wirklich erforderlich sind (z.B. 'statement1.^statement2')
  • die genutzten Identifier sollten die entsprechenden Knoten widerspiegeln (z.B. 'identifier:pragmaLiteral')
  • so wenig Abhängigkeiten von anderen Knoten wie möglich: wenn man z.B. ein Statement Knoten braucht, setzt man einen Punkt, um nicht in FinalStatement geparst zu werden
• im erwarteten Ergebnis immer Helfer-Methoden wie self lf oder self lfTab nutzen, um Code zu sparen und konsistent zu sein

Methoden für Ohm-Knoten

• Aufbau: <Knoten>: aNode with: <Node> and: <Node>
• <Node> wird dabei durch den Typ des entsprechenden Knoten ersetzt
• Singular: mit a / an prefixen, z.B. aMethodHeader
• Plural: den Prefix weglassen und kleinschreiben, z.B. pragmas
• bei mehreren gleichartigen Knoten wird noch other (Plural) oder another (Singular) vorangestellt, z.B. otherPragmas oder anotherStatement
• bei Zeichen wie #, (, ... nehmen wir als Knotenbezeichnung Terminal und demnach als Parametername aTerminal oder terminals

Allgemeine Conventions

• zwischen allen Token (Zeichen, Identifiern, ...) genau ein Leerzeichen
• Tabs zur Einrückung verwenden
• Leerzeile nach dem Methodenheader
• der Name von allen Messages beginnt mit einem Kleinbuchstaben
• Leerzeilen haben keine Whitespaces
• kein Whitespace am Zeilen- oder Methodenende
• alle Zeilen des Methodenbodies sind mindestens einen Tab eingerückt
• Formatierung von OmegaPrint verwenden