Codeformatierung - Max Zeilenlänge?

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));

erik.vikinger

Hallo,

hustbaer schrieb:

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.

Der Breakpoint ist natürlich ein echtes Argument obwohl ich den auch in der Funktion "logging_error()" setzen kann. Auf mehr als 2 Zeilen würde ich solchen Fehlererkennung- /Logging-Kram trotzdem nicht verteilen einfach damit nicht so viel wichtiger Code vom Bildschirm verschwindet.

noobLolo schrieb:

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
    );
}

Also auf 11 Zeilen möchte ich Code der nichts (bzw. nur sehr wenig) zur eigentlichen Funktionalität beiträgt nicht verteilen. Klar ist das vertikale Scrollen unschön aber das muss man ja nur machen wenn mal was an der Fehlermeldung anzupassen ist. Ich denke weniger relevante Dinge dürfen ruhig aus dem Blickfeld verschwinden, man sieht in meinem Beispiel ja an den ersten 30 Zeichen (bei Dir wären es die ersten 4 Zeilen) worum es geht, 11 ganze Zeilen sind IMHO zu viel Bildschirmfläche (links daneben bleibt ja alles leer) für einen Nebenschauplatz.

Grüße
Erik

witte

@DEvent:
Du hast noch nie was mit SAP zu tun gehabt oder?

http://s5b.directupload.net/images/100301/xx8vgdnn.jpg

DEvent

Man dein Beispiel:

// variante 1 (wenn der aufruf von logging_error() "interessant" ist)
if (fehlerVariableX != 0 || fehlerVariableY != 0)
    logging_error(
        errorCode, ERROR_A, 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, ERROR_B, variableA, variableB, variableC);

// 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(WARN_POLLING_TOO_LONG) % pollingIntervalSeconds));

Gleich viel leserlicher. Wieso ihr die Strings nicht als String-Konstanten habt, ist so wieso ein Rätsel. Und Eclipse kann sehr gut umbrechen, gerade so was wie die Parameter.

DEvent

witte schrieb:

@DEvent:
Du hast noch nie was mit SAP zu tun gehabt oder?

http://s5b.directupload.net/images/100301/xx8vgdnn.jpg

LOL. Der Developer sollte sofort verdonnert werden solche Funktionen bis ans Lebensende zu nutzten. Grade in C# wo man doch alle Möglichkeiten hat.

Wie ich das sehe, sind fast alle Parameter als Referenzen. Wieso kann man die nicht in einen Struct oder Class zusammen fassen. Ich denke nicht, dass ein Programmierer wirklich alle überprüfen muss.

DEvent

Nachtrag:
Die 80 Zeichen/Zeile sind nicht dazu dann, damit man den Code auf kleinen Monitoren sehen kann oder damit man ihn ausdrucken kann. Die Begrenzung zwingt einen dazu gut leserlichen Code zu schreiben. Und dazu zählt: a) keine 100 Parameter für eine Funktion, b) für Strings lieber String-Konstanten zu nehmen, keine komplizierten If, For, While zu verwenden, usw.

Es ist die gleiche Logik, dass man Funktionen auf eine Bildschirmhöhe begrenzen sollte.

erik.vikinger schrieb:

Also auf 11 Zeilen möchte ich Code der nichts (bzw. nur sehr wenig) zur eigentlichen Funktionalität beiträgt nicht verteilen. Klar ist das vertikale Scrollen unschön aber das muss man ja nur machen wenn mal was an der Fehlermeldung anzupassen ist. Ich denke weniger relevante Dinge dürfen ruhig aus dem Blickfeld verschwinden, man sieht in meinem Beispiel ja an den ersten 30 Zeichen (bei Dir wären es die ersten 4 Zeilen) worum es geht, 11 ganze Zeilen sind IMHO zu viel Bildschirmfläche (links daneben bleibt ja alles leer) für einen Nebenschauplatz.

hatte vor einiger zeit auch die tendenz immer schön den bildschirm zu füllen, weil ich dachte das macht es einfacher, bzw. besser zu lesen oder wie auch immer, mittlerweile bin ich anderer meinung. es gibt doch keine regel die besagt das ein einzeiler besser als 10 zeilen sind, natürlich kann man es auch übertreiben...

@Bapi_Bupa_Create_Form_Data:
das ist ja eine krankheit, ein normaler mensch kommt so idr. mit 7 variablen klar die er halbwegs gleichzeitig im gedächtnis behalten kann und nicht mit geschätzten 35 aber gut da sieht man mal was dabei raus kommt wenn eine truppe ibm entwickler software entwickelt, mag ja gut sein aber der 08/15 coder blickt da nicht mehr durch

Ich bleibe auch nach möglichkeit bei 80 Zeichen. Wenn es aber mal vorkommt, das ich schon 4 tabs vorgestellt habe, kann es auch mal (sehr selten) vorkommen, das es ein paar mehr Zeichen werden.

Und auch hauptsächlich, weil mans im terminal noch prima angucken kann

witte

DEvent schrieb:

Wie ich das sehe, sind fast alle Parameter als Referenzen. Wieso kann man die nicht in einen Struct oder Class zusammen fassen. Ich denke nicht, dass ein Programmierer wirklich alle überprüfen muss.

Diese Proxy-Klassen werden vom SAP-Connector aus den Meta-Exchange-Daten des SAP-Systems generiert und entsprechen den ABAP-Funktionsbausteinen im SAP-System. Der Java-Connector baut ebenfalls solche Klassen. Ich hoffe ja auch dass ich SAP erst wieder anfassen muss wenn dieses C# vsn 4 die alternative Konstruktorsyntax mit den Zuweisungen erlaubt (null-Argumente wollten die Funktionen nicht akzeptieren wenn ich mich richtig erinnere).
...wollte nur mal anmerken dass das die wirklichen Herausforderung des Code-Formattierens ist.

pumuckl

@logging_error: Ich würd nie Die Fehlermeldung im einfach so unter meinen Code mischen. Schlimmstenfalls habe ich sie wie von DEvent vorgeschlagen als Konstanten irgendwo sammeln. Besser noch in eine Klartext-Datei auslagern von wo aus sie in das Programm generiert oder zur Laufzeit geladen werden kann.

if (fehlerVariableX != 0 || fehlerVariableY != 0)
    logging_error(errorCode, "ERROR_TEXT_30556", variableA, variableB, variableC);

@hustbaers Funktionen: 4-5 Argumente sind too much. 3 gehen noch. 2 sind besser, 1 ist ideal. Im gegebenen Fall seh ich beidesmal systemName und systemKeyName. Klingen ähnlich, werden zusammen benutzt, gehören sicherlich zusammen. -> struct systemNames. Beidesmal zusammen mit einem weiteren Namen. Das werden sicher nicht die einzigen Stellen sein (oder bleiben) wo die alle zusammen benutzt werden -> nächste Struct. Macht 3 und 2 Argumente und deutlich kürzere Zeilen.
Mal davon abgesehn dass die Benutzung von wstring zum einen und wchar_t C-Style Strings zum anderen in der selben Source stinkt :P. Da war also offenbar jemand zu faul fürs Refactoring, und dann isses auch kein Wunder wenn die Zeilenlängen ausm Ruder laufen.
JM2C

@SAP: auch wenns generiert ist, offenbar muss sich den Code hin und wieder ein Entwickler anschauen. => nicht wartbar, Generator fürn Arsch. Kein Wunder dass die so teuer sind, bei den Aufwänden die sie für ihren Code fahren müssen

hustbaer

@DEvent:
Sehe ich ganz anders. Ich finde meine Variante 10x übersichtlicher. Das was richts raussteht, ist Code, den man kaum jemals lesen muss. Zum Verständnis was abgeht, wenn jemand den Code nicht kennt, reicht der Anfang der Zeile, der Teil der auf jedem Schirm Platz hat. Wieso also 13 Zeilen für etwas verschwenden was nur 3 Zeilen braucht? Die 10 Zeilen andere Dinge die ich dadurch mehr auf den Bildschirm bringe, verschaffen wesentlich mehr übersicht, als die uninteressanten Informationen die dadurch rechts rausstehen.

Ich habe "deine" Variante auch an vielen Stellen, aber eben selektiv dort, wo es Sinn macht.

Wieso ihr die Strings nicht als String-Konstanten habt, ist so wieso ein Rätsel.

Weil es unübersichtlich ist, und für dieses Projekt Overkill. Bei Format-Strings führt das bloss dazu, dass man Fehler bei der Übergabe der "Replacement-Objects" macht.

@pumuckl:
4-5 Argumente sind zu viel... pfuh... weil?
Meine Erfahrung aus der Praxis: was du beschreibst klingt in der Theorie nett, aber führt zu extrem unflexiblem Code. Haste schnell structs die drei Dinge zusammenfassen, wovon du dann an einer stelle nur zwei brauchst. Was machste dann? Nochmal auseinanderreissen in zwei structs? Oder in die 3. Variable nen Dummy-Wert reinschreiben? Oder erst wieder die zwei Werte an der Stelle dann ohne Struct ... ? Oder?
Was du schreibst ist natürlich nicht Unsinn, nur fange ich wesentlich später damit an. Sicher nicht wegen 3-4 Werten die ich an 2-3 Stellen zusammen rumreiche.

Und nochwas: schreibst du dir für alle API Funktionen (WinAPI oder was auch immer) eigene Wrapper, damit du auf < 3 Parameter kommst? Ich hoffe nicht...
JM2C