Markus studiert!

Codingstandards

Für das Projekt haben wir uns auf Codingstandards geeignet, die wir mit Hilfe von Cobertura auch in Eclipse und in der Continuous Integration überprüfen.

Da mit Cobertura auch Tests auf Basis von regulären Ausdrücken ausgeführt werden können, konnten wir auch den C#-Quellcode des Frontendteams zumindest rudimentären Tests unterziehen. Unsere Cobertura-Checks finden sich hier.

Coding-Standards für Quellcode

• Zeilenenden: Unix
• Codierung: UTF-8
• Einrückung:
  • Backend: Tab (kein Tab vor Code auf oberster Ebene)
  • Frontend: Space (kein Space vor Code auf oberster Ebene)
• Code-Dokumentation
  • Jede Quellcode-Datei muss mindestens den Namen des Autors enthalten
  • Jede Klassen-Deklaration muss mindestens den Namen des Autors enthalten
  • Methoden-Deklarationen sollten den Namen des Autors enthalten. Wenn alle Methoden einer Klasse von einem Autor erstellt wurden, kann dieser Hinweis entfallen.
  • bei mehreren Autoren, oder Erweiterungen durch eine zweite Person wird die Liste der Autoren erweitert
  • es darf ein selbstgewähltes Kürzel verwendet werden, dieses Kürzel muss in der Datei AUTHORS im Projekt-Root beschrieben werden
  • Sprache der Code-Dokumentation: deutsch oder englisch
• Identifier werden englisch benannt.

Coding-Standards für Commit-Kommentare

Zu jedem Commit muss es ein aussagekräftiges Kommentar geben.

Schlechte Beispiele sind z.B.:

• Fix
• Blubb
• .

Gute Beispiele sind z.B.:

• Behebe Darstellungsfehler in der Tabellen-Komponente. See #8.
• Korrigiere Syntaxfehler. Fixes #9.
• Neue Methode zum Rotieren von Bildern dazu. See #10.

Referenzen auf Tickets

Noch besser ist die Verwendung von Referenzen auf Tickts in den Kommentaren.

Trac erkennt dabei eine bestimmte Syntax in den Kommentaren, die  hier
erläutert ist, und fügt einen Verweis in den Kommentaren zum jeweiligen
Ticket ein.

Beispiel:

• Behebe Darstellungsfehler in der Tabellen-Komponente. See #8, #9, #11
• Korrigiere Syntaxfehler. Fix #4
• Neue Methode zum Rotieren von Bildern dazu. See #18 and #19

Der große Vorteil davon ist, dass man zu jedem Commit automatisch den Verweis auf das Ticket mit der Aufgabenbeschreibung hat und in jedem Ticket die Commit-History zu sehen ist.

Mit der  Mylyn-Integration von Trac bekommt man dann auch fremde Commits an seinen eigenen Tickets mit.

Webinar zur Verwendung von Mylyn.

Änderungen am Quellcode

Zu jeder Änderung muss es ein Ticket geben, auf das beim committen referenziert werden muss.

Ist so ein Ticket nicht vorhanden, muss dieses angelegt werden.

Änderungen am Quellcode, der zu einem anderen Team gehört, ohne Absprache mit dessen Teamleiter sind nicht erlaubt.

Wenn es Probleme mit der Implementieren des anderen Teams gibt, gibt es zwei Möglichkeiten, eine Änderung / Anpassung des Codes zu bewirken:

1. Einen Bug zu melden
2. Ihr macht euch eine Kopie des Codes via svn copy und bearbeitet diese. Anschließen kann der geänderte Code vom zuständigen Team wieder integriert werden.