Natürlich scheiden sich auch an diesem Thema die Geister, weil man sich in Geschmacksfragen so schön streiten kann.
Ein Quelltext der regelmäßig auf Schönheit hin formatiert wird, macht natürlich einen übersichtlichen Eindruck. Allerdings hat man praktisch nie die Zeit zu solchen Formatierungen und jede kleine Änderung mach das schöne Bild wieder kaputt.
Zeitgemäß scheint ein Stil zu sein, der einen Kompromiss von Übersichtlichkeit und schneller Änderbarkeit findet.
Beispiele |
Harmlos |
a.Top = b.Top; // x-Koordinate des Fensterursprungs a.Left = b.Left; // y-Koordinate des Fensterursprungs...hier werden Gleichheitszeichen und gleiche Dinge quasi tabellarisch untereinander gesetzt, der Quelltext ist luftig und leicht zu überblicken. Nachteil: kommt eine weitere Zeile hinzu, z.B. Color sind die beiden anderen fällig, lästig bei VersionsKontrolle.
Anstrengend |
void bewegePunkt3D( int* ortX, int* ortY, int* ortZ, int deltaX, int deltaY, int deltaZ );...genau wie vorher, nur dass man noch wesentlich mehr Arbeit damit hat, vor allem, wenn man den Funktionsnamen ändert.
Abhilfe für "Anstrengende" Formatierung |
Es hat sich für mich als sinnvoll erwiesen, auch solche Schönheits-Formatierungen im Projekt zu standardisieren und zu automatisieren. Ein weiteres Eclipse-JDT-Killer-Feature sind dessen Code Formatter, die man gemeinsam verwalten kann. Ein Ctrl-Shift-F vor dem Speichern gewöhnt man sich schnell an (und ist dann immer ganz perplex ausserhalb von eclipse).
Gefährlich |
dst.upperLeft = src.upperLeft; dst.bottomRgt = src.bottomRgt;...hier wird um der "Schönheit" willen bereits die Lesbarkeit geopfert Right ist zu lang und so wir es abgekürzt, damit die Bezeichner gleichbreit sind. Solche Sachen gibts wirklich. Das erinnert mich ein bisschen an die Art Ordnung, die entsteht, wenn jemand dein Zimmer aufräumt und alle Zettel nach Format (A4, A5, A6...) stapelt. --wp