Table of Contents
Code
spezielle Dateien im Quellverzeichnis
DEVELOPMENT.wiki
CHANGELOG.wiki
README.wiki
LICENSE.txt
Versionierung
FAQ
Präsentation
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
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 Wort
anfang
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>
spezielle Dateien im Quellverzeichnis
DEVELOPMENT.wiki
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
CHANGELOG.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
README.wiki
natürlich auch formatiert in DokuWiki-Syntax
beinhaltet mehrere Abschnitte:
Beschreibung, was der Quellcode tut (evtl. Motivation)
Installationsanleitung
Adressen, bei denen man Hilfe bekommt (eMail,
IRC
, Jabber, …)
Richtlinien zur Mitarbeit (wohin kommt mein verbesserter Code? Kann ich bezahlen, um Feature X zu bekommen?)
Liste der Leute, die zum Projekt beigetragen haben
Links zu Konkurrenzprojekten und Beschreibung, warum diese ein Haufen Scheiße sind
sollte nach Möglichkeit
vor
dem Quellcode geschrieben werden
Beispiel
readme.wiki
LICENSE.txt
Ist wohl selbsterklärend
Kann auch nach der jeweiligen Lizenz (GPLv3.TXT, CC-BY-SA_4.TXT) benannt werden
Versionierung
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
FAQ
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.
Präsentation
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