Die folgenden Beispiele dienen dazu, die (meiner Meinung nach) wenig zeitgemäßen Formatierungen darzustellen. Wirklich gute Beispiele habe ich deshalb weggelassen, denn an ihnen kann man nicht viel sehen. Nur soviel: Wenn man mit Einrückung, einzelnen Leerzeichen und einzelnen Leerzeilen (im Sinne der Konventionen des jeweiligen Projekts) ist die Lesbarkeit meist gut und der Quelltext liest sich angenehm. Wesentlich ist die volle Ausnutzung der Möglichkeiten der Sprache und der eigenen Ideen, um den Quelltext inhaltlich auf Draht zu halten. --WolfPeuker |
Die folgenden Beispiele dienen dazu, die (meiner Meinung nach) wenig zeitgemäßen Formatierungen darzustellen. Wirklich gute Beispiele habe ich weggelassen, denn an ihnen kann man nicht viel sehen. Nur soviel: Wenn man mit Einrückung, einzelnen Leerzeichen und einzelnen Leerzeilen (im Sinne der Konventionen des jeweiligen Projekts) ist die Lesbarkeit meist gut und der Quelltext liest sich angenehm. Wesentlich ist die volle Ausnutzung der Möglichkeiten der Sprache und der eigenen Ideen, um den Quelltext inhaltlich auf Draht zu halten. --WolfPeuker |
:: Der Quelltext wird komplett durchformatiert und nicht nur virtuell, sondern das originäre Sourcefile wird manipuliert. Deswegen ist es so wichtig, die Einheitlichkeit des Formatter zu gewährleisten, weil das sonst ganz fatale Konsequenzen hätte (alles schon erlebt: auch das konvertieren von Tabs zu Whitespace und die dementsprechende Änderung jeder Zeile nach dem commit eines Kollegen). Die Eclipse-Formatter sind aber so beschaffen, dass der Code nach dem Formatieren einen (kanonischen) Endzustand erreicht. |
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