Credits

CSCM - Forschungsgruppe Kooperationssysteme München

CommunityMirrors ™ sind ein Projekt der Forschungsgruppe Kooperationssysteme an der Universität der Bundeswehr München.

Stats

  • Total Stats
    • 16 Authors
    • 17 Posts
    • 143 Tags
    • 58 Comments
    • 10 Comment Posters
    • 3 Links
    • 15 Post Categories
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

Coding Guidelines

  1. Alle Klassen sind mit einer ausführlichen Funktionsbeschreibung mittel JAVADOC (Eclipse /** + Enter über dem Klassennamen) zu versehen. Bei Autoren ist neben Vor- und Nachname auch eine E-Mail-Adresse anzugeben.
  2. Alle Eigenschaften und Methoden sind ausführlich im Code zu dokumentieren. Dies trifft insbesondere auf Parameter und Rückgabewerte zu.
  3. Komplexe Funktionen sind mit zusätzlichen Kommentaren in den Methodenrümpfen zu versehen, damit der Programmablauf zu jeder Zeit für Dritte nachvollziehbar bleibt.
  4. VariablenNamen sind aussagekräftig zu wählen (statt “ItemPanelObject i” besser “ItemPanelObject itemPanelObject”) und beginnen mit einem Kleinbuchstaben
  5. Alle Kommentare und AUCH ALLE Variablennamen / Klassennamen sind in nachvollziehbarer englischer Sprache zu verwenden.
  6. ALLE Änderungen an der vorhandenen Struktur sind im Blog zu kommunizieren
  7. Eigene Klassen / Erweiterungen sollten grundsätzlich IMMER abgeleitet (extends) werden. Direkte Eingriffe in die bestehenden Strukturen sind zu vermeiden..
  8. Objekte der Datenebene werden nur über die zur Verfügung stehenden “Libraries”, Search oder den Controller aus der GUI aufgerufen.
  9. Wildes “Herumreichen” von Objekten ist unter allen Umständen zu vermeiden. Objekte haben eine klare Zugehörigkeit, die auch eingehalten werden sollte.
  10. Zugriffe auf Theme-Dateien (Images, etc.) erfolgen ausschließlich über die ThemeLibrary
  11. Alle Laufzeitparameter / globale Konstanten sind entweder über das Constants-Interface auf oberster Package-Ebene oder über eine der properties-Dateien zu definieren.
  12. Zusätzliche eigene Konfigurationsdateien (z.B. .ini, etc.) sind zu vermeiden.
  13. In den SVN wird nur lauffähiger Code eingecheckt. Vor einem Check-in ist der Code mit den verschiedenen Themes und den verschiedenen Testdatensätzen auf seine Lauffähigkeit zu prüfen.
  14. Bei JEDEM check-in im SVN ist im Kommentarfeld eine aussagekräftige Erklärung in englischer Sprache anzugeben, welche Änderungen vorgenommen wurden und wie sich diese möglicherweise auf andere Klassen auswirken.
  15. Alle externen Libraries werden im Ordner lib ebenfalls eingecheckt. Bei einer Änderung der Libraries ist darauf zu achten, dass die .classpath Datei des Eclipse-Projets ebenfalls eingecheckt wird.
  16. Externe JARs sind entsprechend ihres Projektnamens (alles kleinbuchstaben) zu benennen inkl. Angabe der (Sub-)Versionsnummer, d.h. z.B. prefuse-1.3.4.jar.
  17. Verwendete externe Libraries sind mit einem txt-file zu versehen, aus dem die Nutzungsbedingungen / Lizenz hervorgehen und das den gleichen Namen wie die JAR-Datei hat, nur mit Endung .txt. Für das Beispiel oben also prefuse-1.3.4.txt.
  18. Änderungswünsche an der Struktur oder dem Aufbau des CMF sind jederzeit herzlich willkommen und sollten über dem Blog kommuniziert werden.

Leave a Reply