Diskussion:Programmierstil

aus Wikipedia, der freien Enzyklopädie

[Bearbeiten] Zeilenlänge

Das Java-Beispiel ist eines, das sich in der Tat relativ schlecht umbrechen läßt, weil einfach viele Konstruktor-Aufrufe mit meist nur einem Argument geschachtelt werden. Für diesen entarteten (aber zugegebenermaßen häufigen) Fall ist mir keine verbreitete Konvention bekannt. Es gibt aber Beispiele, die sehr viel mehr von Zeilenumbrüchen profitieren; z. B. wenn jeweils mehr als ein Argument übergeben wird.

Beispiel:

   public ModelAndView handleList(HttpServletRequest request,
                                  HttpServletResponse response)
   throws ServletException {
       //...
   }

Eclipse z. B. kann ein solches Format automatisch erzeugen, wenn die Zeilenlänge ansonsten den eingestellten Maximalwert überschreiten würde. Was es AFAIK nicht kann, ist eine einzige lange Zeile "on the fly" in vergleichbarer Weise umzubrechen; in diesem Fall wird allenfalls an Wortgrenzen umgebrochen, oder der hintere Teil rutscht (irgendwann ganz sicher) nach rechts aus dem sichtbaren Bereich. Der Platz auf dem Monitor ist m. E. zu schade, um ihn für überlange Zeilen zu verpulvern.

Es mag ja sein, daß viele Zeilen "trotz ihrer Länge leicht verständlich" sind; bei sinnvollem Umbruch lassen sie sich aber praktisch "auf einen Blick" erfassen, sind also "noch viel leichter" verständlich. Der Verzicht auf sinnvolle Umbrüche ist m. E. eher der Faulheit geschuldet als einer tatsächlich verbesserten Lesbarkeit (und die Faulheit ist kein Argument mehr, wenn die Umbrüche von der IDE geleistet werden).

"In einem guten Editor kann man eine umbrochene Zeile deutlich von einer neuen Zeile unterscheiden." − Das ist zwar meistens richtig (und hängt manchmal von den getätigten Einstellungen ab), ist aber dann ohne Belang, wenn der Zeilenumbruch an sich nicht signifikant ist, sich für den Compiler also als stinknormaler Whitespace verhält. Das Auge hat dennoch mehr Arbeit damit, die nur an Wortgrenzen umgebrochene Token-Suppe aufzulösen.

"In einem normalen Java-Programm wäre die Zeile bei einer Einrückungstiefe von vier Leerzeichen pro Block mindestens 140 Zeichen lang." – In ihrem jetzigen Zustand ist die Zeile 129 Zeichen lang. Wie stellt sich denn der Autor dieses Satzes einen Umbruch der Zeile vor? Meinem Eclipse fällt hierzu nichts ein; manuell würde ich es vielleicht so machen (leider immer noch 108 Zeichen):

out = new PrintWriter(new OutputStreamWriter(new BufferedWriter(new FileOutputStream(new File(baseDir,
                                                                                              "test.txt"))),
                                             "utf-8"));

oder auch jeweils die geöffneten Klammern umbrechen, um noch etwas Breite zu sparen.

Aber entartetete Beispiele (wie sie von Java leider begünstigt werden) sind kein Grund, generell darauf zu verzichten, den Sourcecode lesbar zu formatieren.

[Bearbeiten] Die Empfehlung

Mit der vorhandenen Empfehlung − "Man sollte im Zweifelsfall immer prüfen, ob das Umbrechen der Zeile die Lesbarkeit tatsächlich erhöht. Tut sie das nicht, sollte man lieber nicht umbrechen." − bin ich nicht einverstanden. Eine nach semantischen Kriterien umgebrochene Anweisung ist immer lesbarer als wenn sie sich auf eine Breite von über 100 Zeichen erstreckt; eine nicht sinnvoll unterteilbare Anweisung leidet nicht, wenn man sie einfach an Wortgrenzen umbricht, wobei z. B. der Ausdruck in einer Zuweisung stets auf der rechten Seite des Gleichheitszeichens bleibt. Wenn Tools dabei helfen können, sollte man sie auch benutzen.

Meine Empfehlung wäre:

• man bleibe mit der Zeilenlänge soweit möglich innerhalb des Druckbereichs (üblicherweise maximal 80 Zeichen in einem monospace-Font) und dessen, was sich am Bildschirm ohne Kopfbewegung auf einen Blick erfassen läßt
• wenn Tools beim Umbrechen helfen können, sollte man sie benutzen (und spart sich damit eine große Anzahl bisher empfohlener Einzelfallprüfungen)
• ansonsten ist der Aufwand gegen den Nutzen abzuwägen; 200 Zeichen lange Zeilen sind aber eine ergonomische Katastrophe, die glücklicherweise immer vermeidbar ist.

--Tobias 16:40, 13. Nov. 2006 (CET)