Ja, da stimme ich prinzipiell zu. Ich kriege das gerade nicht mehr pointiert formuliert, aber ich bin durchaus auch der Ansicht, dass die Lesbarkeit von „Code“ nicht unter einem artifiziellen „Coding-Standard“ leiden sollte. Mein klassisches Beispiel dazu ist die Kodierung der Ausgangskonfiguration der Figuren eines Schachbretts, also einer 8x8-Struktur. Coding Standards enthalten gern „ein Array-Element pro Zeile“-Klauseln, die für so was nicht wirklich praktikabel sind, weil „8 Elemente pro Zeile“ in diesem Fall sehr viel verständlicher wäre.

Ich finde auch das Schreiben von HTML-Code (oder insbesondere von HTML-Templates, die serverseitige Instruktionen enthalten) oft sehr unbefriedigend, weil sich die „80-/120-Zeichen-Regel“ meines Erachtens nicht für Fließtext eignet. Es ist etwa super umständlich, den Text beim nachträglichen Hinzufügen von Wörtern entsprechend neu umzubrechen. Für derlei Fälle will man eher einen Editor, der von der Darstellung her geschickt automatisch umbricht. Editoren, die das wirklich gut machen, gibt es leider wenige, weil die meisten Editoren nicht „Programmcode“ und „Fließtextinhalt“ gleichzeitig sinnvoll unterstützen. Ich schreibe deshalb de facto oft Programmcode mit einer IDE (z. B. NetBeans) und HTML-Code/Fließtexte mit einem anderen Editor, der auf autowrap eingestellt ist (jEdit, Geany, …).

Für mich sind das allerdings auch getrennte Anforderungen. Bei Programmcode halte ich eine Begrenzung auf 80 Zeichen/in Ausnahmefällen 120 Zeichen durchaus für sinnvoll.

Andererseits muss man schon sagen, dass es nicht das Ziel sein sollte, möglichst hübsche Ascii-Bildchen zu malen, sondern einfach lesbaren Code zu produzieren. Deshalb finde ich es etwa auch nicht sinnvoll, Strings im Programmcode unnötig umzubrechen, da das beispielsweise den Einsatz von Übersetzungstools wie gettext oder auch von einer Suche nach Phrasen erschweren kann.

Wiederum andererseits sind das aber durchaus Ausnahmefälle. Wenn ich davon spreche, dass eine Begrenzung auf ~80 Zeichen durchaus ihren Sinn hat, beziehe ich das primär auf Logikcode, der mehr oder weniger ausschließlich aus Instruktionen besteht. Dort hilft eine Begrenzung auch dabei, die Komplexität verwaltbarer zu gestalten, weil die Begrenzung zum Beispiel eine Richtlinie ist, übertrieben tiefe Schachtelung von Kontrollstrukturen zu vermeiden.