Ich muss ja sagen dass ich codetechnisch ein sehr aufgeräumter Mensch bin.
Was wahrscheinlich daran liegt dass ich hauptsächlich in C++ programmiere und unsauberer oder undurchgängiger Stil dort unglaublich schnell die Lesbarkeit beeinträchtigt.
Aus gegebenem Anlass (mein Projekt wird immer größer) möchte ich nochmal betonen wie wichtig es für jeden Programmierer es ist sich eine praktikable Variante der ungarischen Notation anzugewöhnen.
Natürlich gibt es noch einiges mehr Optimierungsraum:
- Achtet darauf eure Deklarationsdateien (Sprich headerfiles) nicht für Definitionen zu missbrauchen (mit der Ausnahme von Template-Definitionen), dazu gehören Macros: Wenn ihr solche verwenden müsst, achtet darauf dass der Code kurz bleibt, wie gesagt, Deklarationsdatei und so.
- Globale Variablen sind zuallererst einmal als Designfehler zu sehen. Berechtigung haben sie nur sehr selten, und mit OOP hat das Ganze nichts mehr am Hut.
Falls man doch meinen sollte sie zu brauchen: Zugriff sollte in C++ durch ::name umgesetzt werden. - Lasst die Unterstriche aus Variablenbezeichnungen raus! Klar, ungarisch für Präfixe und so, aber: Innerhalb der Bezeichnung haben die Dinger nichts verloren.
my_map_start_iterator = m_mp_my_map.begin() kann keiner lesen, itStart = m_mp.begin(); genügt völlig. - Intelligente Namen geben. Zum Beispiel ist die Bezeichnung strText ziemlich sinnfrei.
- Stress sparen kann man sich auch in Funktionsaufrufen. Wird ein benutzerdefinierter Typ übergeben ist es am klarsten den Parameternamen gleich dem Typ zu setzen:
LoadModel(Model* toLoad) ist pfui, ebenso LoadModel(Model* model3ds) und LoadModel(Model* reference) auch, LoadModel(Model* model) dagegen hui. - Abkürzungen bitte nicht konsequent großschreiben: getHTMLPage() wird zu getHtmlPage().
- Redundanzen vermeiden was Namen angeht. Eine Matrix-Klasse benötigt keine Funktion InvertMatrix() und eine Klasse Gui (man bemerke: G groß, Rest klein) benötigt keine Methode ShowGui(). Der Aufruf gui.show(); ist schneller und angenehmer zu lesen.
- Private Variablen sollten mit einem Unterstrich gekennzeichnet werden. _transformationMatrix oder transformationMatrix_ geht gleichermaßen – Beides lässt keinen Zweifel darüber aufkommen dass die Variable extern niemanden zu interessieren hat.
- Meine Klassen erweitere ich mit einem Präfix als Indikator um welches Design Pattern es sich handelt:
C – Normale Implementierung
I – Interface
S – Singleton
T - Template
Dass dies Standard ist glaube ich nicht, aber mir hiflt es wirklich sehr.
- Nutzt kluge Umbrüche wenn die Zeile nicht reicht! Rechnungen nach dem nächsten Operator umbrechen, couts nach dem nächsten << und so weiter. Horizontale Scrollbalken haben im Editor nichts zu suchen. Achtet dabei auch darauf dass nicht jeder einen 24″ Bildschirm mit 16:10 Verhältnis besitzt und brecht dementsprechend früh um.
- Nutzt Boolean-Variablen um bedingte Ausdrücke zu vereinfachen:
if ( (lstToDo.size() = 0 && !IsCalculation) || lstErrorCodes.size() !=0){ ist sehr, sehr schlecht.
Besser ist:
bool isDone = lstToDo.size() == 0 && !isCalculating;
bool isError = lstErrorCodes.size() = 0;
if (isDone || isError){ - Benutzt die Leertaste!
for(int i=0;i<arr.length();i++)
arr[i]+=(newPos+thisPos)*1/2;
Grauenhaft.
for (int i = 0; i < arr.length(); i++)
arr[i] += (newPos + thisPos) / 2;
Besser. - Der Raum Zwischen Methoden und Klassen kann nicht unterschätzt werden. Ich persönlich lasse zwischen Methoden 2 Leerzeilen, zur nächsten Klasse 4.
- Kommentare sollte es viele geben, allerdings sollten sie auch eine Aussage haben.
coords.x++; // increment x by 1
ist dumm.
coords.x++; // move player to the right
ist besser. - Kommentare sind englisch.
Immer. - Rückt Kommentare bündig ein. Selbsterklärend. Kommentare sollten nicht die Sicht nehmen weil sie kreuz und quer im Code liegen. Dazu gehört auch, ganz wichtig:
- Soweit möglich, Kommentare hinter den Zeilen postieren, nicht über dem zu kommentierenden Code. Letzteres ist vor Methoden und Klassen schön übersichtlich, nicht jedoch im fließenden Code.
Außnahme: Man erläutert die Aufgabe eines kompletten Codeblock. Das macht man dann natürlich vor dem Block.
- Achtet als generelle Regel darauf dass die Kommentare den Codefluss nicht stören oder unterbrechen, jedoch schnell zu sehen sind wenn man etwas vom Code nicht versteht.
- Über Klassen kommt bei mir zusätzlich eine Kommentarlinie die den Namen enthält, darunter eine kleine Definition:
//————————————–CVec3f——————————————
// Data structure holding three floating point coordinates and allowing all necessary vector operations
// through its’ overloaded operators.
Darunter (zu den 4 Leeren Zeilen darüber!) nochmals eine Leerzeile und dann der Klassenrumpf.
Es gibt der Regeln sicherlich noch hunderte mehr, aber soviel sprang mir gerade in den Kopf. Wer noch was wichtiges auf dem Herzen hat der sei Willkommen in den Kommentaren noch was zu schreiben 