Meine liebe Hassliste

[Swordfish]

...

[volkard]

Och, was mir spontan einfällt,

• kein using namespace std verwenden und doch ausschließlich std- und boost-sachen verwenden. Als wenn es was bringen würde. Glaube, einige machen das, weil es professioneller aussieht.

• Gamecoding

• delete p; p=nullptr;
  Dann lese ich schon gar nicht mehr weiter.

• Funktionen mit vielen Parametern, vielen Zwecken und viel Code.

• Quatsch-Optimierungen wie >>1 statt /2, inline-asm für Sachen, die der Compiler viel besser kann, new statt vector weil evtl schneller, Schleifenvariable i als char statt int, um Bits zu sparen...

• Seitenweise Lizenzen, Coyright und so für Code, den keiner geschenkt haben mag.

• Stümperhaftes Nachbauen von Features aus Java/Pascal, statt nach dem C++-Weg sich mal zu informieren.

• Verspieltheit: Verliebtheit in Sprachfeatures und in saukomplexen Code, den man gerade gebacken hat, das Schaffen von Begriffen und einführen von massig Abstraktion für was Alltägliches, nur um ein paar Zeilen zu sparen. Und das dann auch noch in die boost-libs zufügen dürfen.

[mhnjmgf]

int xyz;
//1000 Zeilen Code
xyz = 9; //hier wird xyz zum ersten mal verwendet.

[hustbaer]

* "Verkehrte" Tests ala if (10 < digit)
* Plenken funktion ( parameter );
* Anti-Plenken for(ex;ex2;ex3)
* Plenk-Casts ala Funktion((Foo*)variableVomTypZeigerAufFoo);
* C-Style Casts
* Code-Duplizierung ala

CString msg;
msg.Format("PREFIX-DEN-DER-KUNDE-VERLANGT: %s - FunktionsnameAusgeschriebenStatt__FUNCTION__Makro: Wah, Fehler: %d\n", time, blub);
LogThisShit(msg);
// Und das an 1000 Stellen wiederholt

* Code-Duplizierung ala

if (bar)
{
    if (foo)
    {
        Statement1;
        Statement2;
        Statement3;
        Statement4;
        // ...
        // In Wirklichkeit 20+ Zeilen pro Block
    }
    else
    {
        Statement1;
        Statement2-mit-mini-Modifikation;
        Statement3;
        Statement4;
    }
}
else
{
    if (foo)
    {
        Statement1;
        //Statement2; // TODO: blub
        Statement3;
        Statement4;
    }
    else
    {
        Statement1;
        Statement2;
        Statement3-mit-mini-Modifikation;
        Statement4;
    }
}
// Das geht auch 3 Levels tief (und ja, das meine ich ernst)

• CMeineKlasse
• dwMeineVariable
  * Frühere Versuche auskommentiert stehen gelassen, weil man könnte den Code ja nochmal brauchen
• // TODO: irgendwas was ziemlich wichtig klingt, und garantiert nicht "TODO" sein sollte, wo man aber doch nicht 100% sicher sein kann ob es überhaupt noch TODO ist (weil's ja vielleicht wo anders passiert, oder der TODO-schreiber einfach nur besoffen war)
  * Sinnfreie "Mein Bildschirm is so klein *wein*" Abkürzungen in Namen (Funktionen, Klassen, Variablen)
  * 1000+ Zeilen Funktionen
  * 5000+ Zeilen (handgeschriebene!) Source-Files
  * Code der, wenn man versucht Abhängigkeiten aufzuzeichnen, zum Bild eines Wollknäuls führt
  * Deutsche Bezeichner
  * Deutsche Kommentare
  * commentarys in evil englisch so that them very hart too read are
• #defines mit super kollisionsfreien Namen ala COUNT , möglichst noch in Header Files
  * super kollisionsfreie Variablen-/Funktions-/Klassennamen im globalen Namespace

[hustbaer]

volkard schrieb:

[*]Quatsch-Optimierungen wie >>1 statt /2, inline-asm für Sachen, die der Compiler viel besser kann, new statt vector weil evtl schneller, Schleifenvariable i als char statt int, um Bits zu sparen...

+1
Und bitte noch gleich mit Kommentar dabei warum das (was nachweislich nix bringt oder sogar schadet) die supercoole Optimierung ist

mhnjmgf schrieb:

int xyz;
//1000 Zeilen Code
xyz = 9; //hier wird xyz zum ersten mal verwendet.

+1, hab ich vergessen

[Gast]

Am schlimmsten finde ich die dreisten Verurteilungen von nicht-optimalem Code, die man überall lesen kann, welche die Hemmschwelle von nicht mit 100%igem Selbstbewusstsein gesegneten Kodierergenossen, irgendwann einmal mit Übungsaufgaben zufrieden zu sein oder diese herzuzeigen, derart stark nach oben setzen! Kommt mir wie eine Meute vor, die irgendwie nur darauf wartet, jemanden in der Luft zerreißen zu können. Und nicht nur das, wenn gerade nichts zur Hand ist, wird das Zerreißen in eigenständigen Threads auf die Meta-Ebene gehievt

[knivil]

Defaultargumente.

[SideWinder]

knivil schrieb:

Defaultargumente.

Weil?

MfG SideWinder

[Kümmelkorn]

Ich mag vor allem keine unleserlichen Quellcodes, also vor allem keine oder schlechte einrückung, keine Kommentare und Variablennamen nach dem Motto "Rate-mal-was-ich-bin" (letzteres bezieht sich nicht auf i als Zählvariable).

volkard schrieb:

[*]Quatsch-Optimierungen wie >>1 statt /2, inline-asm für Sachen, die der Compiler viel besser kann, new statt vector weil evtl schneller, Schleifenvariable i als char statt int, um Bits zu sparen...

Darf man (als Anfänger, der gerade C nochmal tiefer lernen will) fragen, woran man Quatsch-Optimierungen von Nicht-Quatsch-Optimierungen unterscheidet? Gelten deine Beispiele nur für C++ oder auch für C? Warum ist z.b. char statt int bzw. >>1 schlecht? (Ich frage aus Interesse und weil ich was lernen will und nicht, weil ich klugscheißen will o.ä.)

[volkard]

knivil schrieb:

Defaultargumente.

+1

[Erkenner der Klugscheisse]

Kümmelkorn schrieb:

(Ich frage aus Interesse und weil ich was lernen will und nicht, weil ich klugscheißen will o.ä.)

Ja, von wegen die Tricks die kenne ich schon du willst von deiner Klugscheisserei ablenken!

Du gehörst zur Kategorie: Ober Klugscheisser

Aber auch die erkenne, ich habe bereits 40 Jahre Erfahrung im erkennen von Klugscheissern du machst mir nichts vor!

[volkard]

Kümmelkorn schrieb:

Darf man (als Anfänger, der gerade C nochmal tiefer lernen will) fragen, woran man Quatsch-Optimierungen von Nicht-Quatsch-Optimierungen unterscheidet?

Man kann sie eigentlich nicht erkennen, wenn man nicht selber mal den Quatsch vorher selber gemacht hatte und später herausfand, daß es Quatsch war.

Weißt Du, warum ich so schnell Fehler in fremdem Code finde? Weil ich den Fehler, den ich dann da mal wo finde, selber dutzende male gemacht hatte. Wenn ich Programmierschulungen mache und nur drei Sekunden auf den Bildschirm gucken muss, um den Fehler zu sehen und helfend eingreifen zu können, hat das nix damit zu tun, daß meine Brille besonders gut wäre (sie ist aber auch gut), und nix damit, daß ich besonders gut programmieren könnte (naja, ich halte mich für recht gut, schon), sonder damit, daß ich mich an meine Fehler erinnere.

Kümmelkorn schrieb:

Gelten deine Beispiele nur für C++ oder auch für C?

Die beiden, die Du fragst, beide, ja.

Kümmelkorn schrieb:

Warum ist z.b. char statt int

a) Der Prozessor mal Intel/AMD angenommen hat einige Register. Davon lassen sich AX, BX, CX, DX wenn ich mich recht erinnere in kleinere Register aufteilen. Sowas wie AH. Es gibt aber noch viele andere Register, die nur int-size können. Will der Compiler den char in AH oder so eins tun, steigt der Registerdruck!! Will er ihn in ein anderes tun, muss er im Prinzip immer bei jeder Rechnung noch ein &0xff zufügen.

Registerdruck:=
Oh, finde keinen gescheiten Link. http://en.wikipedia.org/wiki/Register_allocation
Naja, je mehr Register der Compiler zur Verfügung hat, desto besser kann sein Optimierungsergebnis sein. Binde ich Register für bestimmte Zwecke, nehme ich ihm Freiheuten und das bestraft sich darin, daß er nicht mehr optimal arbeiten kann.

b) Liegt die Laufvariable eh auf dem Stack. Wenn man von dem ein Byte anfordert, kriegt man mindestens vier Bytes, also int-size. Weil Speicherzugriffe auf Adressen, die durch 4 teilbar sind, deutlich schneller gehen. Die Variable, die nach dem char innerhalb der Schleife angelegt werde4n wird, wird die drei unbenutzen Bytes überspringen, um eine Schnell-Variable zu sein.

c) Liegt die Laufvariable vermutlich eh in einem Register und braucht eben ein Register. Und sonst gar nix.

d) Und wenn nicht, dann hat man trotzdem (üblicherweise) 1M Stack. Wozu 3 Bytes sparen, wenn man dabei Laufzeiteinbußen hat?

Kümmelkorn schrieb:

bzw. >>1 schlecht?

Weil es die Sache nicht ausdrückt!
Gestern oder vorgestern bei mir passierte:

map<uint32_t,size_t> primfaktoren;
    while(n%2==0){//Optimierung von hier
        ++primfaktoren[2];
        n/=2;
    }//bis hier
    for(uint32_t t=3;t*t<=n;t+=2){//damit hier +=2 geht
        while(n%t==0){
            n/=t;
            ++primfaktoren[t];
        }
    }
    if(n!=1)
        ++primfaktoren[n];

Soweit klar.
Das war eine mathematische Optimierung.
Aber

while((n&1)==0){//Optimierung von hier

verkneife ich mir, denn damit verlasse ich die mathematische Sprache und gehe runter aufs Bitgefummle. Ich WEIß, daß der optimierende Compiler genau den selben Trick auch von alleine macht. Alle kleinen Trick kann der schon.

Kümmelkorn schrieb:

(Ich frage aus Interesse und weil ich was lernen will und nicht, weil ich klugscheißen will o.ä.)

Schon klar. die Klugscheißer lernt man mit der Zeit im Forum kennen.
Vermutlich hält mich auch der eine oder andere dafür, weil nicht immer sachlich bleibe, sondern auch Sachen ausspreche, die gegen bestimmte Glaubensbekenntnisse gehen, obwohl ich deren Glaube nicht wissenschaftlich widerlegen kann.

edit: Aus gegebenem Anlass, die "Kenner d..." und neu "Erkenntnis..." kannste beruhigt als Forenpest ignorieren.

[Ein ehemaliger Benutzer]

Bin ich der einzige, der keine Hassliste für fremden Code hat? Jeder der hier drin seine Hassliste auflistet, hat in seinem Code Sachen, die bei jemand anderem in ner Hassliste stehen.

Warum soll man sich über sowas aufregen?

[Dobi]

Einrückung, Planks usw. interessieren mich kaum. Wenn ichs nicht lesen kann, lass ich einfach eine automatische Code-Formatierung drüberlaufen.

Defaultargumente, mhh interessant. Mir ist noch nix nerviges damit untergekommen. Habt ihr ein Beispiel?

Mich nerven besonders ewiglange Funktionen, vorallem wenn da viel ohne RAII gemacht wird und man immer aufpassen muss. Generell eigentlich alles, mit dem man unnötig viel Zeit verbringen muss, nur weil irgendwer zu doof oder gar faul war. Und wenn es dann bei nem Kunden crasht, der ursprüngliche Entwickler aber schon lange nicht mehr da ist, und ich es debuggen darf ...

@TravisG: Weils manchmal Spaß macht, sich zu ägern.

[Swordfish]

...

[volkard]

TravisG schrieb:

Bin ich der einzige, der keine Hassliste für fremden Code hat?

Ja, könnte sein.

Fremden Code zu debuggen ist so unglaublich schwieriger als eigenen zu debuggen...
So unglaublich viel aufwändiger. Faktor 4, wenn der andere extrem gut ist, so gut wie Bashar, Shade oder so.
Kann aber gerne mal auf 10 oder exorbitant gehen.

TravisG schrieb:

Warum soll man sich über sowas aufregen?

Wir Programmierer regen uns doch nicht auf wegen sowas. Wir können hassen, ohne, daß der Blutdruck steigt. Sonst wären wir alle tot.

Wenn ich wiedermal als Admin was mache, dann ist es schon fast regelmäßig, daß der Kunde sehr gut vorgebildet ist, wie man mit Rechnern umgeht. Ich mache genau das, was er auch tun würde, nur gebe ich nicht nach 20 Minuten auf, sondern kämpfe mich durch, selbst wenn es 2 Stunden dauert. Wiedermal von MS und Adobe Steine in den Weg gelegt kriegt, die Hardware von der Bezugsstelle taugt nix, der im Unternehmen zwangsweise eingesetze Virenscanner ist dummkonfiguriert...
Na, und?
Die ersten Programme hinzukriegen war viel unergiebiger. Die ersten Speicherlöcher in C zu stopfen, allein sie zu erkennen!
Ich löse also sein Problem. Und er schaut mich mit großen Augen an. Gibt zu, daß er schon drei Fachleute vorher befragt hatte, die aufgegeben hatten.

Einfach dran bleiben. Und insbesondere so lange fummeln und frickeln, bis ein Geistesblitz kommt. Der kommt nicht von alleine, sundern dadurch, daß man dran bleibt und sich reinvertieft.

Am Ende habe ich nur gemacht, was der Kunde auch hätte machen können, nur ich rege mich eben nicht auf, sondern frickele mich durch. Und wenn's wieder mal eine besondere Gemeinheit gibt, die ich erkenne, dann lache ich, zeige auf den Bildschirm und lache die Gemeinlinge aus. Letztendlich sichern die Gemeinlinge, Laientreiberprogrammierer und Lügedokumentierer ja auch, daß Informatiker immer mal einen schnellen Euro machen können.

[cooky451]

volkard schrieb:

new statt vector weil evtl schneller

Da vector alles initialisiert, kann unique_ptr<T[]> uU durchaus schneller sein.

[volkard]

Swordfish schrieb:

hustbaer schrieb:

* Plenken funktion ( parameter );

Fällt

if( !foo ) { bar( 43 ); }

in das Schema?

Das ist doch hübsch.

Ich würde schreiben

if(!foo){
   bar(43);
}

also antiplenk.

Kaputt wird es bei

if (!foo) {
   bar (43);
}

Ich kann mich nicht entscheiden, wohin mit den Spaces.

if ( ! foo ) {
   bar ( 43 ) ;
}

?
Nee.

if( !foo ) {
   bar( 43 );
}

Nee.

if( !foo and !bar ) {
   bar( 43 + 5*7 - 3 + pow ( 10 , 3*2 ) );
}

Nee. Stattdessen stelle ich in der IDE die Schriftart groß, sehr groß, ungemein groß, das würdet Ihr nicht glauben. Für mich ist das der beste Weg.

[volkard]

cooky451 schrieb:

volkard schrieb:

new statt vector weil evtl schneller

Da vector alles Initialisiert, kann unique_ptr<T[]> uU durchaus schneller sein.

Kennst Du push_back?

Ok, der Zeiger kann schneller sein. push_back verbrät eine Inkrementierung und eine Fallunterscheidung pro Einfügung, 2 Takte?
Falls man mit den Daten dann was berechnet, ist es vollkommen Latte, was push_back kostete.

Und ich bin ein Freund davon, sich selber Container zu schreiben, die halt an das Problem noch besser angemessen sind als die Standardcontainer. Bei vector<T> zum Beispiel habe ich eine Alternativ-Implemetierung Vector<T,size_t>, die intern nicht new benutzt, sondern ein std::array. Manchmal, ganz ganz selten, bläst das ganz gut. Vorstellbar als Container, der zu eriner Schach-Stellung die möglichen Züge aufnimmt. Aber fast immer ist vector echt vollkommen ok und kein zehntel Prozent Performance-Nachteil kann befürchtet werden.

Wer zerstört im Exception-Fall die Objekte, die per placement-new in den unique_ptr<T[]> gestopft wurden?

[cooky451]

Du denkst da an den falschen Anwendungsfall. Manchmal will man einfach nur 100 MB Speicher am Stück haben, der dann später beschrieben wird - std::vector fährt da dann erstmal mit einem memset drüber. Aber ja, die Anwendungsfälle halten sich schon in Grenzen, ist nur etwas, das mir eingefallen ist.