Codeformatierung - Max Zeilenlänge?

Kümmert ihr euch beim Programmieren noch um sowas wie maximale Zeilenlänge, damit man den Code z.B. drucken kann?

EXDW

Nö.
Bei WPF auch nahezu unmöglich

SideWinder

DaVüsch schrieb:

Kümmert ihr euch beim Programmieren noch um sowas wie maximale Zeilenlänge, damit man den Code z.B. drucken kann?

Drucken interessiert mich nicht, aber ich lasse Eclipse meinen Java-Code auf 160 Zeichen pro Zeile begrenzen.

Auch habe ich eine alte Angewohnheit Header-Kommentare, etc. auf 80 Zeichen zu begrenzen. Liegt aber rein am Design. Also Länge der Zeile als reines Mittel der Lesbarkeit.

MfG SideWinder

volkard

DaVüsch schrieb:

Kümmert ihr euch beim Programmieren noch um sowas wie maximale Zeilenlänge, damit man den Code z.B. drucken kann?

Ich versuche 80. Bei großen Kommentaren halte ich das sogar ein.

Bashar

Ich halte mich auch weitestgehend an die 80. Wenn es mal auf 100 geht ist es auch nicht so wild, ausdrucken tut man Code ja eher selten. Aber wenn ich mir ein Diff von zwei Versionen derselben Datei angucke, will ich nicht allzuviel scrollen müssen. Auch ist es ganz nett, den Editor nicht immer maximieren zu müssen.

Bashar schrieb:

Aber wenn ich mir ein Diff von zwei Versionen derselben Datei angucke, will ich nicht allzuviel scrollen müssen.

Da sind 2 Monitor praktisch.

Bashar

Hab ich, ändert nichts. Das Scrollen fällt weg und wird durch ermüdende Augenbewegung ersetzt

Walli

Ich breche um, wenn es logisch erscheint. Auch mag ich nicht seitlich scrollen. Codes drucke ich nur selten aus, und wenn nur stellenweise, deswegen spielt das keine Rolle.

rüdiger

Früher habe ich mich an 80 Zeichen/Zeile gehalten. Aber da muss man oft dann umständlich umbrechen und stört den Lesefluss. 100 Zeichen/Zeile finde ich definitiv besser.

rüdiger schrieb:

Früher habe ich mich an 80 Zeichen/Zeile gehalten. Aber da muss man oft dann umständlich umbrechen und stört den Lesefluss. 100 Zeichen/Zeile finde ich definitiv besser.

dito

Shade Of Mine

Walli schrieb:

Ich breche um, wenn es logisch erscheint.

Mach ich genauso. Es gibt heutzutage keine fixen limits, also benuzte ich soft limits. Wenn etwas zulange wirkt als dass man es direkt verstehen kann, teile ich in mehrere Zeilen auf.

dh, aber auch, dass ich sachen teile die nicht zulange waeren. zB

bool operator==(PLETHO const& lhs, PLETHO const& rhs) {
    return 
        lhs.left == rhs.left
        &&
        lhs.right == rhs.right
    ;
}

hustbaer

also wenn hartes limit, dann IMO min. 120 zeichen. alles darunter ist ein witz.
ich achte aber nicht strikt darauf.
mal mehr, mal weniger, meistens weniger.

@shade: genau, sowas mache ich auch.
dafür breche ich dann oft sachen nicht um, die einfach nur lange werden. funktion mit 10x namespace::namespace::etc. mit 100 parametern und sowas. wird auch schneller mal länger als 80/100/120.

DEvent

rüdiger schrieb:

Früher habe ich mich an 80 Zeichen/Zeile gehalten. Aber da muss man oft dann umständlich umbrechen und stört den Lesefluss. 100 Zeichen/Zeile finde ich definitiv besser.

Umständlich umbrechen, benutzt du Notepad?
Eclipse formatiert den Code automatisch wenn ich ihn speichere und ich gebe mich mit 80 Zeichen zufrieden.

hustbaer schrieb:

also wenn hartes limit, dann IMO min. 120 zeichen. alles darunter ist ein witz.
ich achte aber nicht strikt darauf.
mal mehr, mal weniger, meistens weniger.

@shade: genau, sowas mache ich auch.
dafür breche ich dann oft sachen nicht um, die einfach nur lange werden. funktion mit 10x namespace::namespace::etc. mit 100 parametern und sowas. wird auch schneller mal länger als 80/100/120.

WoW, mit deinem Code will ich nichts zu tun haben.

volkard

DEvent schrieb:

rüdiger schrieb:

Früher habe ich mich an 80 Zeichen/Zeile gehalten. Aber da muss man oft dann umständlich umbrechen und stört den Lesefluss. 100 Zeichen/Zeile finde ich definitiv besser.

Umständlich umbrechen, benutzt du Notepad?
Eclipse formatiert den Code automatisch wenn ich ihn speichere und ich gebe mich mit 80 Zeichen zufrieden.

hustbaer schrieb:

also wenn hartes limit, dann IMO min. 120 zeichen. alles darunter ist ein witz.
ich achte aber nicht strikt darauf.
mal mehr, mal weniger, meistens weniger.

@shade: genau, sowas mache ich auch.
dafür breche ich dann oft sachen nicht um, die einfach nur lange werden. funktion mit 10x namespace::namespace::etc. mit 100 parametern und sowas. wird auch schneller mal länger als 80/100/120.

WoW, mit deinem Code will ich nichts zu tun haben.

Benutzt Du Java?

erik.vikinger

Hallo,

ich hab mal für einen Auftraggeber gearbeitet der zwingenst 80 Zeichen pro Zeile verlangt hat. Das Argument das man Code eher am Bildschirm als auf Papier bearbeitet hat leider nichts gezählt. Das hat im Endefekt an einigen Stellen zu schwer- bis un-lesbaren Code geführt. An einigen ganz kniffligen Stellen ist es einfach unmöglich sich daran zu halten (man kann in VHDL nicht ganz so flexiebel umbrechen wie z.B. in C) was man dann dort immer mit viel Gezäter dann doch akzeptiert hat (aber man musste sich für fast jede Stelle einzeln rechtfertigen). Das ging auch anderen Kollegen dort so.

Alles im Allem bin ich persönlich der Meinung das es Quatsch ist sich sklavisch an bestimmte derartige Vorgaben zu halten. Natürlich sollte man die Zeilen nicht zu lang werden lassen, es ist IMHO wichtig den eigentlich Programmfluss möglichst gut im Überblick zu haben, Nebensächliches kann man aber auch schon mal etwas neben dem Hauptblickfeld positionieren.
Zeilen wie diese muss man IMHO nicht umbrechen, die sollte eher so wenig wie möglich wertvolle Bildschirmfläche (also Zeilen) verdecken.

if ( (fehlerVariableX != 0) || (fehlerVariableY != 0) ) { logging_error(errorCode,"sehr lange/ausführliche Fehlermeldung mit verschiedenen nützlichen Angaben.\n",variableA,variableB,variableC); }

DEvent schrieb:

Eclipse formatiert den Code automatisch wenn ich ihn speichere und ich gebe mich mit 80 Zeichen zufrieden.

Solche Auto-Formatierer finde ich persönlich schrecklich, ich gestallte meinen Code lieber selber und manchmal auch anhand spezieller Kriterien. Sowas ist sicher auch persönliche Geschmackssache.

Grüße
Erik

zwutz

ich lasse bei mir bei 120 Zeichen eine Linie einblenden. Komme ich drüber, schau ich nach, ob ich umbrechen kann. Wenn nicht, ist es auch egal
Zu lange Zeilen sind beim drüberlesen einfach eine unnötige Bremse. Dazu kommen evtl. eingeblendete Seitenleisten, die den Editor etwas schmaler machen.
80 Zeichen sind in Zeiten von Breitbildmonitoren aber unsinnig.

rüdiger

DEvent schrieb:

rüdiger schrieb:

Früher habe ich mich an 80 Zeichen/Zeile gehalten. Aber da muss man oft dann umständlich umbrechen und stört den Lesefluss. 100 Zeichen/Zeile finde ich definitiv besser.

Umständlich umbrechen, benutzt du Notepad?
Eclipse formatiert den Code automatisch wenn ich ihn speichere und ich gebe mich mit 80 Zeichen zufrieden.

Nicht der Prozess des Umbrechens ist aufwendig, sondern die richtige Stelle zu finden, damit man den Lesefluss nicht stört und das ganze halbwegs leserlich bleibt. Ich glaube nicht, dass das ein Tool vernünftig hinbekommt.

knivil

Was habt ihr alle gegen 80 Zeichen pro Zeile. Ich beschraenke mich darauf, da das Standardterminal halt diese Einstellung hat. Dafuer kann ich dann aber auch mehrere Terminals nebeneinander oeffnen und habe mehr Ueberblick. Diese Breite einzuhalten faellt mir nicht schwer, ich produziere auch keine unsinnigen Zeilenumbrueche. Auch kann man bei den meisten IDEs Codebloecke zusammenklappen, ob das auch horizontal klappt, weiss ich aber nicht.

erik.vikinger schrieb:

Zeilen wie diese muss man IMHO nicht umbrechen, die sollte eher so wenig wie möglich wertvolle Bildschirmfläche (also Zeilen) verdecken.
if ( (fehlerVariableX != 0) || (fehlerVariableY != 0) ) { logging_error(errorCode,"sehr lange/ausführliche Fehlermeldung mit verschiedenen nützlichen Angaben.\n",variableA,variableB,variableC); }

das ist alles eine geschmacks frage, ich finde das schon zu lang, und würde daraus eher mehr zeilen machen, aber nicht sagen daraus muß man mehr zeilen machen (fast wie goto das man "nicht verwenden sollte")

if((fehlerVariableX != 0)
|| (fehlerVariableY != 0)){
    logging_error(
        errorCode
        ,"sehr lange/ausführliche Fehlermeldung"
         " mit verschiedenen nützlichen Angaben.\n"
        ,variableA
        ,variableB
        ,variableC
    );
}

das problem bei deinem einzeiler ist, das ich dann statt vertikal horizontal scrollen muß. Aber 80 find ich auch gelegentlich etwas wenig, und wenns mal etwas mehr ist find ichs auch nicht schlimm, bin aber der meinung, dass überlange zeilen eher nicht die lesbarkeit fördern

hustbaer

noobLolo schrieb:

erik.vikinger schrieb:
Zeilen wie diese muss man IMHO nicht umbrechen, die sollte eher so wenig wie möglich wertvolle Bildschirmfläche (also Zeilen) verdecken.
if ( (fehlerVariableX != 0) || (fehlerVariableY != 0) ) { logging_error(errorCode,"sehr lange/ausführliche Fehlermeldung mit verschiedenen nützlichen Angaben.\n",variableA,variableB,variableC); }
das ist alles eine geschmacks frage, ich finde das schon zu lang, und würde daraus eher mehr zeilen machen, aber nicht sagen daraus muß man mehr zeilen machen (fast wie goto das man "nicht verwenden sollte")
if((fehlerVariableX != 0)
|| (fehlerVariableY != 0)){
    logging_error(
        errorCode
        ,"sehr lange/ausführliche Fehlermeldung"
         " mit verschiedenen nützlichen Angaben.\n"
        ,variableA
        ,variableB
        ,variableC
    );
}
das problem bei deinem einzeiler ist, das ich dann statt vertikal horizontal scrollen muß. Aber 80 find ich auch gelegentlich etwas wenig, und wenns mal etwas mehr ist find ichs auch nicht schlimm, bin aber der meinung, dass überlange zeilen eher nicht die lesbarkeit fördern

Also ich würde hier sicher nicht alles in eine Zeile schreiben. Schonmal deswegen, weil man dann keinen Breakpoint mehr auf "logging_error()" setzen kann - zumindest nicht einfach.
Eher so:

// variante 1 (wenn der aufruf von logging_error() "interessant" ist)
if (fehlerVariableX != 0 || fehlerVariableY != 0)
    logging_error(errorCode, "sehr lange/ausführliche Fehlermeldung  mit verschiedenen nützlichen Angaben.\n",
        variableA, variableB, variableC);

// variante 2 (wenn der aufruf von logging_error() eher uninteressant ist, was in diesem fall wohl zutrifft)
if (fehlerVariableX != 0 || fehlerVariableY != 0)
    logging_error(errorCode, "sehr lange/ausführliche Fehlermeldung  mit verschiedenen nützlichen Angaben.\n", variableA, variableB, variableC);

@DEvent

WoW, mit deinem Code will ich nichts zu tun haben.

Du Mädchen!

Ein paar Beispiele aus dem Leben gegriffen:
(Längenangaben inklusive einrückung, tab = 4)

// 166 zeichen
			EventLogLogonObserver ello(systemName.c_str(), m_connectionString.c_str(), m_sqlTimeout, lastProcessedRecordPropertyName.c_str(), systemKeyName.c_str());

// 163
	void StartThread(std::wstring const& systemName, std::wstring const& lastProcessedRecordPropertyName, std::wstring const& systemKeyName, long pollingInterval)

// 190
						WriteLogMessage(str(boost::wformat(L"WARNING: Polling interval too short (%d seconds) - using the minimum allowed interval (2 seconds).") % pollingIntervalSeconds));