Sinnvolle Formatierung vieler geschachtelter Kontrollstrukturen

volkard

tntnet schrieb:

Das sieht wirklich grässlich aus. Ein wichtiger Tipp ist, viel mehr Leerraum zu lassen.

Nö. Alle vermeidbaren Leerzeichen müssen weg. Dafür ruhig die Schrift größer stellen.

5cript

Leere Zeilen, für kleine 'Sinnabschnitte' halte ich jedoch für ziemlich Lesbarkeitsfördernd. Wenn diesen Sinnabschnitten hier und da noch ein kleiner Kommentar vorausgeht, umso besser.

Außerdem: Lieber mehr tippen, als Namen zu kryptische Abkürzungen zu machen. Es sei denn die Variable wird wieder so lang, dass man zu lange braucht um sie zu lesen.

volkard schrieb:

tntnet schrieb:

Das sieht wirklich grässlich aus. Ein wichtiger Tipp ist, viel mehr Leerraum zu lassen.

Nö. Alle vermeidbaren Leerzeichen müssen weg. Dafür ruhig die Schrift größer stellen.

(Not sure if troll or serious...)

for(int i=2;i<10;++i)

vs

for(int i = 2; i < 10; i++) // preferable

Allerdings:

someFunc ( i + otherFunc ( 2 , 3 ) , 10 ); // igitt

Wie bereits erwänht ist es ratsam ein paar style guides zu überfliegen und sich das rauszupicken, was man selbst mag. Oder man entscheidet sich für ein und richtet sich nach dem.

EDIT: Ich halte es außerdem für ratsam sich nicht von dem Style der STL (snake case) leiten zu lassen. Das ist meiner Meinung nach boost und STL vorbehalten, sowie C libs.

Erhard Henkes

Alle vermeidbaren Leerzeichen müssen weg.

Das meinst Du nicht ernst, oder etwa doch?

volkard

Erhard Henkes schrieb:

Alle vermeidbaren Leerzeichen müssen weg.

Das meinst Du nicht ernst, oder etwa doch?

Hin und wieder poste ich doch in diesem Forum Code, oder? Du hast schon tausende von Code-Snippets von mir gesehen.

Hoffentlich ist aufgefallen, daß mein Code die Tendenz hat, besser lesbar zu sein als vergleichbarer Code von anderen.

Und meistens habe ich keine vermeidbaren Leerzeichen drin. Anscheinend fällt es bei mir nicht so auf, kann mich gerade nicht dran erinnern, deswegen mal angemeckert worden zu sein. Nubes hingegen werden ständig deswegen angemeckert. Das läßt mich schließen, daß es nicht an den Leerzeichen liegt.

volkard

5cript schrieb:

for(int i=2;i<10;++i)

vs

for(int i = 2; i < 10; i++) // preferable

Allerdings:

someFunc ( i + otherFunc ( 2 , 3 ) , 10 ); // igitt

Ähm, wenn die Leerzeichen wenigstens Sinneinheiten zusammenfassen würden

for( int i=2 ; i<10 ; i++ ) // preferable

dann könnte ich sie mir gefallen lassen. Aber genau das geschieht nicht. Es geht sogar soweit, daß man in Styleguides vollständige Regeln reinschreibt, wo Leerzeichen hingehören. Genau dann kann man sie auch vollständig weglassen. Es ist bloß eine Sache der Gewöhnung.

for(int i = 2; i < 10; i++) // preferable

for(int i = 2; i < 10; i += 1) // preferable

Vor dem letzten i ist ein Leerzeichen entstanden, weil ich '++' durch '+= 1' ersetzt habe. Muss das denn sein?

tntnet

volkard schrieb:

Erhard Henkes schrieb:

Alle vermeidbaren Leerzeichen müssen weg.

Das meinst Du nicht ernst, oder etwa doch?

Hin und wieder poste ich doch in diesem Forum Code, oder? Du hast schon tausende von Code-Snippets von mir gesehen.

Hoffentlich ist aufgefallen, daß mein Code die Tendenz hat, besser lesbar zu sein als vergleichbarer Code von anderen.

Und meistens habe ich keine vermeidbaren Leerzeichen drin. Anscheinend fällt es bei mir nicht so auf, kann mich gerade nicht dran erinnern, deswegen mal angemeckert worden zu sein. Nubes hingegen werden ständig deswegen angemeckert. Das läßt mich schließen, daß es nicht an den Leerzeichen liegt.

Hach ja, das ist doch so ein Thema, wo man stundenlang diskutieren kann ohne dass jemand wirklich recht oder unrecht hat . Und selbst ich kann meine Klappe nicht halten .

Leerzeilen finde ich wichtig:

if (cond1)
{
    func1();
}
if (cond2)
{
    func2();
}

finde ich irritierend. Da sieht es aus, als hätte das 2. if irgendwas mit dem 1. zu tun.

if (cond1)
{
    func1();
}

if (cond2)
{
    func2();
}

ist ok. Da sieht man auf dem ersten Blick, dass die 2 ifs tatsächlich nichts miteinander zu tun haben.
Dagegen:

if (cond1)
{
    func1();
}
else if (cond2)
{
    func2();
}

ist ok und soll so sein, da diesmal das "else if" tatsächlich zum ersten if gehört.

Übrigens ist es typographisch genormt, dass vor einem Satzzeichen kein Leerzeichen und danach eines geschrieben wird. Und daran halte ich mich auch beim Schreiben von Code.

hustbaer

5cript schrieb:

for(int i = 2; i < 10; i++) // preferable

Wenn man jetzt noch das "after-flowcontrol-keyword" Leerzeichen spendiert

for (int i = 2; i < 10; i++) // MUCH preferable

dann ist man da wo man hin sollte.

Ich habe mir mal das erste Stueck genommen:

while(ncounter_bip < MAX_VAR_MUSTER) {
    for (ik=0; ik<ADSIZE; ++ik) {
        hilfsneuronen_bip[ik] = 0;
        for (il=0; il<ADSIZE; ++il) {                        
            hilfsneuronen_bip[ik] = hilfsneuronen_bip[ik] + adjazenz_bip[ik][il] * neuronen_bip[il];
        } //Update Regel  

        if (hilfsneuronen_bip[ik] > threshold)  //Treshold
            hilfsneuronen_bip[ik] = 1;                                              
        else
            hilfsneuronen_bip[ik] = 0;
    }

    for (ik=0; ik<ADSIZE; ++ik) {
        neuronen_bip[ik] = hilfsneuronen_bip[ik];
    }

und dann daraus das gemacht:

void updateHilfsNeuron(size_t ik)
{
    for (size_t il=0; il<ADSIZE; ++il) 
    {                        
        hilfsneuronen_bip[ik] = hilfsneuronen_bip[ik] + adjazenz_bip[ik][il] * neuronen_bip[il];
    }
}

void adjustActivation(size_t ik)
{
    hilfsneuronen_bip[ik] = (hilfsneuronen_bip[ik] > threshold) ? 1 : 0;
}

void trainNeuralNet(/* ... */)
{
    while( ncounter_bip<MAX_VAR_MUSTER ) 
    {
        fill( begin(hilfsneuronen_bip), end(hilfsneuronen_bip), 0 );
        for( size_t ik=0; ik<ADSIZE; ++ik) 
        {
            updateHilfsNeuron(ik);
            adjustActivation(ik); 
        }

        copy(begin(hilfsneuronen_bip), end(hilfsneuronen_bip), begin(neuronen_bip)); 
        //...
    }
}

Man sieht: In der while-Schleife gibt es nur noch eine Einrueckebene und die Namen der Hilfsfunktionen verdeutlichen den Algorithmus. Damit sind auch Kommentare ueberfluessig, die sonst bei Aenderungen ja mit gewartet werden muessten.

hustbaer

allman schrieb:

Man sieht: In der while-Schleife gibt es nur noch eine Einrueckebene und die Namen der Hilfsfunktionen verdeutlichen den Algorithmus. Damit sind auch Kommentare ueberfluessig, die sonst bei Aenderungen ja mit gewartet werden muessten.

5cript

hustbaer schrieb:

5cript schrieb:
for(int i = 2; i < 10; i++) // preferable
Wenn man jetzt noch das "after-flowcontrol-keyword" Leerzeichen spendiert
for (int i = 2; i < 10; i++) // MUCH preferable
dann ist man da wo man hin sollte.

ja sehe ich auch so. War ein Fehler

volkard

5cript schrieb:

hustbaer schrieb:
5cript schrieb:
for(int i = 2; i < 10; i++) // preferable
Wenn man jetzt noch das "after-flowcontrol-keyword" Leerzeichen spendiert
for (int i = 2; i < 10; i++) // MUCH preferable
dann ist man da wo man hin sollte.
ja sehe ich auch so. War ein Fehler

Irgendwie macht die IDE den Text blau/schwarz/grün. Dolle Sache das.
Kein Schwein regt sich drüber auf, daß das automatisch passiert. Es gibt auch keine Diskussion darüber, welche Farben man für was benutzen sollte. Die nimmt man einfach so hin. Aber die sind voll hilfreich, vor allem für Anfänger. Als Syntax-Highlighting aufkam, ist meine Produktivität quasi explodiert (es war auch eine Phase, wo ich nicht gar viel planen und forschen musste, sondern als Code-Äffchen LOC machen). Wenn die erwartete Farbe nicht kam beim Tippen, wars ein Tippfehler, den ich sofort korrigieren konnte, statt einen Compilerlauf abzuwarten dafür.

Ich nehme für Integer-Konstanten ROT, weils bestimmt böse magic numbers sind, für String-Literale was ähnliches, normalen Text(Bezeichner) in Hellgrau auf Schwarz(wie auch alles andere statische), Schlüsselwörter in Weiß, Kommentare Dunkelgrau, am Rest bastele ich noch, denn ich habe heute erst angefangen, da mal ein System reinzubringen. In den 80-er hatte ich ein komplettes perfektes System, aber das benutzte leider Hellgrau als Hintergrundfarbe, da war ich einem Zeitgeist erlegen, kurz vorher waren die Schwarz/Weiß-Monitore noch unbezahlbar und die Leuchtfarbe (Grün oder Bernstein) als Hintergund absurd, weißer Hintergrund war das Ultimum an Ergonomie. Geht nicht mehr, sie muss schwarz sein. Zu viele Systeme, zu viele Sprachen und zu viele IDEs, um sich auf Zeitgeister einzuschießen.

Irgendwie macht die IDE den Text blau/schwarz/grün. Dolle Sache das.
Kein Schwein regt sich drüber auf, daß das automatisch passiert. Es gibt auch keine Diskussion darüber, welche Farben man für was benutzen sollte. Die nimmt man einfach so hin.
Aber warum um Gottes Willen kann die IDE denn nicht zwischen "for" und der '(' ein virtuelles Leerzeichen machen??? Es hat keine Bedeutung. Einfach den Kram virtuell anzeigen, obwohl er nicht im Code steht. Ich wäre sogar für ein halbes Leerzeichen für dort. Auch um die ';' im for ein halbes Leerzeichen. Um Operatoren ein drittel Leerzeichen und 1/3 in der ')' und 2/3 außerhalb der ')'. Was hindert Euch?
Das "++" nach der ')' zum Beispiel würde ich ein wenig nach links ziehen und schmusen lassen. Bei "if(a|b&c)" würde ich vielleicht mit viertel Leerzeichen dafür sorgen, daß die Prio ersichtlich ist. Ebenso mit '+' und '*' natürlich.
Was hindert Euch?

Es wird Zeit, die nutzlosen Leerzeichen aus dem Code rauszumachen und der IDE zu übergeben, so wie wir es mit den Farben schon vor vielen Jahren gemacht haben. Oder?

ps: Damit meine ich nur die Leerzeichen innerhalb einer Zeile. Leerzeilen sind ein ganz ganz anderes Problem. Letzteres ist viel weniger wichtig und quasi schon gelöst und so.

hustbaer

@volkard
Ich verstehe komplett überhaupt nicht wieso SO viele Leute gegen die IDE kämpfen.

Bei VS muss man IIRC erstmal ein paar Sachen manuell abdrehen damit man ohne dauernd fluchen zu müssen sowas wie "for(" überhaupt schreiben kann.
Bzw. du kannst es schon so schreiben. Nur sobald du das "{" nach dem for() bzw. den abschliessenden ";" bei "ohne {}" schreibst macht es *hüpf* und das Leerzeichen ist da. Weil "automatically format completed statement", "automatically format completed block" etc.

Falls ich mich irren sollte und man das erst manuell aufdrehen muss bitte korrigiert mich.

Achja, was hindert sie daran? Na dass viele Leute bestimmte Dinge gern visuell ausrichten.

for (.....)              // blah comment
    foo(bar, baz)        // blah other comment

Usw.
Der IDE beizubringen dass sie so virtuellen Leerzeichen einfügt, aber gleichzeitig solche und ähnliche Formatierungen nicht kaputt macht... wäre vermutlich schwer.

Grundsätzlich seh' ich das aber genau so wie du - ich bin der Meinung dass IDEs was die grafische Representation von Source angeht viel viel schlauer werden könnten.

volkard

hustbaer schrieb:

Achja, was hindert sie daran? Na dass viele Leute bestimmte Dinge gern visuell ausrichten.
for (.....)              // blah comment
    foo(bar, baz)        // blah other comment
Usw.

Weil manchen Leuten der vertikale Zusammenhang 
so arg viel wichtiger ist als der horizontale. 
Ich finde das immer sehr hässlich, weils einen 
Zusammenhang vorspiegelt, wo eigentlich keiner 
ist, und das Lesen deswegen schwieriger macht.

int main() {
    size_t  const  max         =  17            ;
    sizt_t         count       =  0             ;
    char    const  filename[]  =  "prms.txt"    ;
    for (     int64_t u = 1; u * u < 1000000000 ; ++ u) {
        for ( int64_t v = 1; v < u              ; ++ v) {
              int64_t c = u * u + v * v         ;
              int64_t a = u * u - v * v         ;
              if (    c > 1000000000 ) break    ;
                    …

Erhard Henkes

Wesentlich ist, dass die Stuktur das Begreifen der logischen Abläufe und Zusammenhänge fördert. Wie das konkret erfolgt ist zweitrangig. Man kann da in einem Programm auch zwischen verschiedenen Styles wechseln. Sie sollten nur block- oder funktionsweise einheitlich sein. Das Anbringen von Kommentaren ist ebenfalls ein Gesichtspunkt.