30.06.2013 Aufrufe

Softwareentwicklung in C++ - ASC

Softwareentwicklung in C++ - ASC

Softwareentwicklung in C++ - ASC

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

A. Cod<strong>in</strong>g-Standard<br />

Der hier angeführte Cod<strong>in</strong>g-Standard ist e<strong>in</strong> Vorschlag, wie e<strong>in</strong> solcher aussehen<br />

könnte. Zu erwähnen wäre, dass die hier abgedruckte Version e<strong>in</strong>e<br />

s<strong>in</strong>nvolle M<strong>in</strong>imalversion für kle<strong>in</strong>e Projekte darstellt. Für große Projekte<br />

s<strong>in</strong>d entsprechend weitere Regeln zu ergänzen.<br />

A.1 Generelle Regeln<br />

Die folgenden Pr<strong>in</strong>zipien s<strong>in</strong>d essentiell für die Lesbarkeit, Wartbarkeit und<br />

Erweiterbarkeit e<strong>in</strong>es Programms:<br />

E<strong>in</strong>fachheit: Das Pr<strong>in</strong>zip der E<strong>in</strong>fachheit ist auch als das KISS-Pr<strong>in</strong>zip (Keep<br />

It Small and Simple) bekannt. Kurz gesagt sollen Methoden, Funktionen<br />

und natürlich auch Operatoren genau e<strong>in</strong>e, für ihren Abstraktionslevel<br />

adäquate, atomare Aufgabe erfüllen. Niemals sollen mehrere Aufgaben<br />

auf e<strong>in</strong>mal erledigt werden, genauso wenig, wie Aufgaben erledigt werden<br />

sollen, die <strong>in</strong> e<strong>in</strong>en anderen Abstraktionslevel gehören (=Durchgriff nach<br />

unten oder oben). Parameterlisten sollen so kurz und übersichtlich wie<br />

möglich gehalten werden. Methoden, Operatoren und Funktionen sollen<br />

als Faustregel niemals mehr als 60 Zeilen lang se<strong>in</strong>. E<strong>in</strong>e durchschnittliche<br />

Länge von ca. 30 Zeilen ist zu bevorzugen. Seiteneffekte s<strong>in</strong>d absolut zu<br />

vermeiden!<br />

Das Pr<strong>in</strong>zip der E<strong>in</strong>fachheit bed<strong>in</strong>gt auch, dass Klassen ke<strong>in</strong>e fetten Interfaces<br />

haben dürfen.<br />

Intuitivität: Das Pr<strong>in</strong>zip der Intuitivität bedeutet, dass man den geschriebenen<br />

Source-Code “wie e<strong>in</strong> Buch” lesen und verstehen können muss,<br />

und zwar ohne Kommentare im Source-Code und ohne Erklärungen des<br />

Programmierers! Damit ist impliziert, dass Variablen-, Methoden- und<br />

Funktionsnamen sprechend (=selbsterklärend) und genau ihrer Funktionalität<br />

entsprechend benannt se<strong>in</strong> müssen. E<strong>in</strong>buchstabenvariablen,<br />

wie z.B. i, s<strong>in</strong>d nicht erlaubt. Unnötige Kommentare werden als störend<br />

erachtet und sollen dementsprechend weggelassen werden. E<strong>in</strong> typisches<br />

Beispiel für solche unnötigen Kommentare wäre:<br />

count++; // and here the counter is <strong>in</strong>cremented

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!