Entwicklerrichtlinien

• Code wird sauber kommentiert
  • guter Code braucht keine Kommentare, aber …
  • … trotzdem sollte der Shit natürlich beim Darüberlesen verständlich sein.
• geforkter und verbesserter Code wird upstream geschickt
  • in regelmäßigen Abständen Pull Requests!

• Code-Smells werden gefälligst vermieden, ihr n00bs.
• Einrückung mit doppelten Leerzeichen
  • Die Tabulator-Taste ist böse!
  • bei bestehenden Projekten von Drittanbietern wird sich natürlich an deren Richtlinien gehalten, falls existent.
• Öffnende und schließende Klammern werden nicht weggelassen!
  • auch nicht, wenn bspw. ein if-Statement aus nur einer Zeile besteht.
• Variablen haben englische Namen, die aus mindestens drei Buchstaben bestehen.
  • der erste Buchstabe ist kleingeschrieben, jeder Wortanfang wird mit einem Großbuchstaben versehen
  • der Variablenname entspricht der Verwendung
    • Beispiel: <fc #FF0000>iKunde</fc> <fc #008000>customerID</fc>
  • Abkürzungen werden vermieden
    • Beispiel: <fc #FF0000>tblKd</fc> <fc #008000>customerTable</fc>

• Entwicklungs-Roadmap in chronologischer Reihenfolge (0.1, 0.1.2, 0.3, 1.0, …)
• Im Wurzelverzeichnis
• Formatiert in DokuWiki-Syntax
• beinhaltet Abschnitte TODO und
• Beispiel development.wiki

• wie DEVELOPMENT.wiki, nur umgekehrt chronologisch sortiert (…, 1.0, 0.3, 0.1.2, 0.1)
• Beinhaltet auch einen Upgrade-Abschnitt für inkompatible API-Änderungen und Upgradehinweise
• Beispiel changelog.wiki

• natürlich auch formatiert in DokuWiki-Syntax
• beinhaltet mehrere Abschnitte:
  1. Beschreibung, was der Quellcode tut (evtl. Motivation)
  2. Installationsanleitung
  3. Adressen, bei denen man Hilfe bekommt (eMail, IRC, Jabber, …)
  4. Richtlinien zur Mitarbeit (wohin kommt mein verbesserter Code? Kann ich bezahlen, um Feature X zu bekommen?)
  5. Liste der Leute, die zum Projekt beigetragen haben
  6. Links zu Konkurrenzprojekten und Beschreibung, warum diese ein Haufen Scheiße sind
• sollte nach Möglichkeit vor dem Quellcode geschrieben werden
• Beispiel readme.wiki

• Ist wohl selbsterklärend
• Kann auch nach der jeweiligen Lizenz (GPLv3.TXT, CC-BY-SA_4.TXT) benannt werden

Versionierung nach SemVer-Schema, Zusammenfassung folgt:

• Bei einer Versionsnummer MAJOR.MINOR.PATCH wird erhöht:
  • MAJOR, wenn man inkompatible API-Änderungen vornimmt
  • MINOR, wenn man Funktionalität in einer abwärtskompatiblen Art und Weise hinzufügt
  • PATCH, wenn man abwärtskompatible Bugfixes durchführt
• Zusätzliche Labels für pre-Release und build-Metadaten sind als Suffix zum MAJOR.MINOR.PATCH-Format zu sehen.
  • Beispiel: 0.1.14-schnitzel

• Wie gehe ich mit Revisionen in der 0.y.z-Entwicklungsphase um?
  • am Einfachsten startet man mit 0.1.0 und erhöht die MINOR-Version für jedes Dev-Release.
• Woher weiß ich, wann ich die 1.0.0 veröffentliche?
  • Wenn der Code in einer Produktivumgebung eingesetzt wird,
  • eine stabile API vorhanden ist
  • oder man sich über Abwärtskompatibilität Gedanken macht.

• Jedes Projekt braucht eine Homepage!
• Wir haben dev.crunchweb.org für Code, der noch nicht flügge ist.
• Projekte sollten mit ihrem eindeutigen Namen als Subdomain von crunchweb.org angelegt werden