Codeformatierung - Max Zeilenlänge?

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

Shade Of Mine

hustbaer schrieb:

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...

Nicht alle APIs sind so grottig wie die WinAPI

hustbaer

Shade Of Mine schrieb:

hustbaer schrieb:

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...

Nicht alle APIs sind so grottig wie die WinAPI

Aber die meisten

DEvent schrieb:

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.

Das ganze stammt sehr wahrscheinlich ursprünglich aus ABAP, da wird ein Funktionsaufruf so formatiert und sieht dann garnicht mehr so schlimm aus.

call function 'APPL_LOG_WRITE_DB'
    exporting
      object                = gc_bal_object
*     subobject             = ' '
*     log_handle            = ' '
*     update_task           = ' '
    tables
      object_with_lognumber = lt_log_logs
    exceptions
      object_not_found      = 1
      subobject_not_found   = 2
      internal_error        = 3
      others                = 4.

abc.w

@alle: Was haltet ihr von einer Limitierung von 60 Zeichen? Lese gerade ein Buch, wo jede Zeile maximal 60 Zeichen enthält (Leerzeichen nicht mitgezählt). Unglaublich aber wahr. Die Seite ist 16 cm breit, davon sind 6 cm frei von Text
Aber, muss zugeben, liest sich gut... da kann man nichts sagen...

*rant*

Interessante Diskussion; das ist ein Thema, mit dem jeder anders umgeht. In meinem Quellcode habe ich es aufgegeben, auf die Zeilenlänge zu achten. Es ist einfach nicht möglich, 80 Zeichen pro Zeile zu forcieren, wenn man bereits mit jedem namespace oder sonstigen Blöcken 4 Zeichen "verliert". Und ich habe auch in mittleren Projekten gerne mal 4- oder sogar 5-stufige Namensräume (Manche Leute empfinden dies als übertrieben, aber ich mag es aufgeräumt). Früher habe ich dennoch versucht, wenigstens die mehrzeiligen Kommentare konsequent auf 80 Zeichen zu formatieren, was ich aber inzwischen auch aufgegeben habe. Meine jetzigen Regeln:

Konsequente Formatierungen sind wichtiger als Zeichenbegrenzungen.
Der Tabulator darf nicht benutzt werden oder muss automatisch mit 4 Spaces ersetzt werden.
Zeilenumbrüche sind, wenn angebracht, jeweils nach dem Komma anzubringen, wobei dann auf die öffnende Klammer eingerückt wird. Als Beispiel seien folgende Snippets gegeben:

inline bgr(const value_type &,
                   const value_type &,
                   const value_type &);

static std::map<const std::type_info *,
                                boost::shared_ptr<pre_gc_rtt_descriptor> > descriptors;
                // ...
                pre_gc_rtt_descriptor(const std::type_info &,
                                      nothing (*)(nothing *const));

aimpl.insert(std::pair<std::wstring,
                               handle<node> >(value->name(), 
                                              value));

Alternativ dazu rücke ich in seltenen Fällen (etwa bei Zuweisungen an Variablen mit langen Namen) auf der nächsten Zeile 4 Spaces gegenüber dem Anfang ein:

resource *const res = 
                    secured_set.find(ref)->second;

Mehrzeilige Kommentare sollten die Zeilenumbrüche immer an ungefähr der gleichen Stelle haben. Das hilft einfach beim Lesen.
...

Das ist alles Teil meines Coding-Styles und den ziehe ich bei meinem Code sehr konsequent durch (will heissen, ich schreibe keinen Code bevor nicht der alte aufgeräumt ist; bin ich jetzt krank? ) und komme so bei mittleren Projekten an den meisten Stellen nicht über 80 Zeichen pro Zeile hinaus. Aber auf der anderen Seite gibts dann durchaus Files, wo dank Namensräumen der Code erst ab Zeichen 100 beginnt. Aber wenigstens ist dieser dann konsequent auf 100 eingerückt.

abc.w schrieb:

@alle: Was haltet ihr von einer Limitierung von 60 Zeichen? Lese gerade ein Buch, wo jede Zeile maximal 60 Zeichen enthält (Leerzeichen nicht mitgezählt). Unglaublich aber wahr. Die Seite ist 16 cm breit, davon sind 6 cm frei von Text
Aber, muss zugeben, liest sich gut... da kann man nichts sagen...

Das geht ja noch recht gut. Ich habe früher oft direkt auf einem TI-89 programmiert, dort hast du im Editor 24 Zeichen pro Zeile. Das ist zu wenig

MfG

Shade Of Mine

Weil ich das jetzt schon ein paarmal lese...

Ich formatiere statt

aimpl.insert(std::pair<std::wstring,
    handle<node> >(value->name(), 
        value));

es lieber so:

aimpl.insert(
    std::pair<
       std::wstring,
       handle<node>
    >(
       value->name(), 
       value
    )
);

bzw. hier wuerde ich eher folgendes machen:

aimpl.insert(
    std::pair<
       std::wstring,
       handle<node>
    >(value->name(), value)
);

ich finde es immer komisch wenn man die schliessende klammer nicht sieht.