Codeformatierung - Max Zeilenlänge?

pumuckl

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

Jein. Ich benutze die API mit den vielen Parametern nur in einer oder wenns hochkommt zwei Schichten von vielen. Und da nur in möglichst wenigen Klassen. Meist muss ich mir eh Adapter für die APIs bauen, weil ich meine Architektur nicht an der Architektur der APIs ausrichte. Mit diesen Adaptern hab ich dann die Verwendung der API-Funktionen eingegrenzt und quasi Wrapper für die API geschaffen.

Th69

Hallo /rant/,

dein Code-Style entspricht in etwa meinem (ich bin doch nicht einzigartig -).

hustbaer

DEvent schrieb:

hustbaer schrieb:

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

Wie soll den jemand, der deinen Code nicht kennt, wissen welcher Code Abschnitt wichtig ist und welcher nicht?

Außerdem, Code, den man nicht regelmäßig zu Gesicht bekommt, neigt dazu vergessen zu werden. Alles Code ist aber wichtig in einem Programm und jede Code Character muss überprüft werden.

Naja ich verstecke den Code ja nicht mit irgendeinem magischen Zauber.
Die Funktionsnamen die am Anfang der Zeile noch sichtbar sind, reichen auch vollkommen aus, damit man weiss was passiert.

In allen drei Zeilen, ist für jemanden der das komplette Programm vor sich hat, sofort klar, was diese Zeilen tun sollen. So lange also kein Grund besteht, anzunehmen, dass sich genau in einer dieser Zeilen ein Fehler verbirgt, muss man die Parameter nicht checken, da man weiss, welche Parameter übergeben werden sollen.
Glaub mir bitte einfach, dass das im Kontext vollkommen klar ist.

Beispiel (erfunden):

void PrintTableData(Data d, Sink s)
{
    // ...
    // ...
    for (size_t i = 0; i < lala; i++)
    {
        // ...
        // ...
        s->Print(d[i].irgendwas, d[i].was, d[i].manNichtmehr, lesenKannWeilsAus, demBildschirmRaussteht);
        // ...
    }
    // ...
    // ...
}

Hier muss ich mir die Parameter zu Print() einfach nicht angucken, um zu "wissen", was Print() wohl machen wird: ein Datenelement aus "d" an die "Sink" schicken, die das dann irgendwo hin "drucken" wird.

Hier den Print() Aufruf über 5 Zeilen zu ziehen, ist also vollkommen unnötig, weil auch so sofort klar ist, was passiert.

----

Ich lese auch selbst oft Code von anderen Leuten, und im Schnitt finde ich mich schneller zurecht, wenn ich viel gleichzeitig am Bildschirm habe, als wenn viele Funktionsaufrufe über mehrere Zeilen verteilt sind.

hustbaer

DEvent schrieb:

TravisG schrieb:
Shade Of Mine schrieb:
aimpl.insert(
    std::pair<
       std::wstring,
       handle<node>
    >(
       value->name(), 
       value
    )
);
Woah... sorry wegen der fehlenden konstruktiven Kritik, aber sowas find ich grässlich.
Ich ebenso. Genauso wie mit den Strings Ist mir wieder ein Rätsel wieso man keine typedefs verwendet.
aimpl.insert(Mypair(value->name(), value));

Es gibt viele (gute) Gründe für Typedefs, also bitte nicht falsch verstehen. Ich will nicht Typedefs nicht schlecht reden.
Zur Abwechslung aber mal ein paar dagegen:

* Overkill. Nicht jeder "komplizierte" Type, den man 2-3 mal wo braucht, muss gleich getypedeft werden. Kostet bloss sinnlos Zeit.

* Namen. Oft ist es sau-schwer, passende Namen für Typedefs zu finden. Ich weiss zwar genau was der Typ "eigentlich" ist, aber oft brauche ich viel zu lange, bis mir ein Name einfällt, der mehr hilft als schadet. Schlechte Namen implizieren oft Dinge, die dann gar nicht so sind. Das ist sehr schlecht.

* Jeder zusätzliche Level-Of-Indirection erschwert das Verständnis, da man ein weiteres Ding nachschlagen muss, bis man zu dem Punkt vorgedrungen ist, wo dann endlich Butter bei die Fische gemacht wird.

Shade Of Mine schrieb:

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

foo-bar! OMG!
Spätestens jetzt sollte einem klar sein, warum es typedefs und defines gibt.

hustbaer

BTW:

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

->

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

->

aimpl.insert(std::make_pair(value->name(), value));

welt wieder in ordnung

Blue-Tiger

TravisG schrieb:

Shade Of Mine schrieb:
aimpl.insert(
    std::pair<
       std::wstring,
       handle<node>
    >(
       value->name(), 
       value
    )
);
Woah... sorry wegen der fehlenden konstruktiven Kritik, aber sowas find ich grässlich.

*zustimm*
ich seh das wie hustbaer

hustbaer schrieb:

BTW:

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

->

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

Und wieso noch der Leerraum zwischen den beiden >

DEvent

hustbaer schrieb:

Ich lese auch selbst oft Code von anderen Leuten, und im Schnitt finde ich mich schneller zurecht, wenn ich viel gleichzeitig am Bildschirm habe, als wenn viele Funktionsaufrufe über mehrere Zeilen verteilt sind.

Man kann sicher Code schneller und besser verstehen, wenn man nicht ständig horizontal scrollen muss, sondern gleich den gesamten Code sieht. Vertikal zu scrollen kostet mich nichts, aber horizontal muss ich erstmal mit der Maus zum Balken. Und wie gesagt, wenn man den Code immer und immer wieder zu Gesicht bekommt, fallen auch Fehler viel schneller auf als wenn man nur die Hälfte des Codes sieht.

Blue-Tiger

DEvent schrieb:

hustbaer schrieb:

Ich lese auch selbst oft Code von anderen Leuten, und im Schnitt finde ich mich schneller zurecht, wenn ich viel gleichzeitig am Bildschirm habe, als wenn viele Funktionsaufrufe über mehrere Zeilen verteilt sind.

Man kann sicher Code schneller und besser verstehen, wenn man nicht ständig horizontal scrollen muss, sondern gleich den gesamten Code sieht. Vertikal zu scrollen kostet mich nichts, aber horizontal muss ich erstmal mit der Maus zum Balken. Und wie gesagt, wenn man den Code immer und immer wieder zu Gesicht bekommt, fallen auch Fehler viel schneller auf als wenn man nur die Hälfte des Codes sieht.

Ich brech auch lieber um bevor ich vertikal scrollen muss, aber bei heutigen Breitbildschirmen muesst ich das vermutlich erst bei 200 oder mehr (ich brech idr. so bei 120 spaetestens um). Klar, wenn ich echt mal in der Shell editieren muss ist das manchmal extrem nervig, aber mehr als 1x pro Monat kommt das nicht vor, also wozu dafuer Lesbarkeit opfern (und ein paar der hier geposteten Zeilenverschwender fallen bei mir absolut unter "sehr schwer lesbar").
Ausserdem hab ich lieber 80 Statements pro Bildschirm als 15

hustbaer

DEvent schrieb:

hustbaer schrieb:

Ich lese auch selbst oft Code von anderen Leuten, und im Schnitt finde ich mich schneller zurecht, wenn ich viel gleichzeitig am Bildschirm habe, als wenn viele Funktionsaufrufe über mehrere Zeilen verteilt sind.

Man kann sicher Code schneller und besser verstehen, wenn man nicht ständig horizontal scrollen muss, sondern gleich den gesamten Code sieht.

Ich muss aber nicht scrollen. Niemand muss horizontal scrollen. Der Teil der sichtbar ist, reicht 100x aus, damit alles klar ist. Ohne scrollen. Wieso dann umbrechen?

Vertikal zu scrollen kostet mich nichts

Doch: Übersichtlichkeit. Und zwar enorm.

hustbaer

sorry, doppelpost