(Tod-)Sünden der Programmierung
Ein Weblog hat mich auf den Gedanken gebracht. Was haltet ihr für die größten Sünden die so in der Programmierwelt verbreitet sind?
Ich leg mal zum besseren Verständniss ein paar Beispiele vor:
Premature Optimization
Heute hab ich doch tatsächlich in einem msdn Forum die Frage gelesen:
Was ist effizienter StringBuilder.AppendLine() oder StringBuilder.Append( Environment.NewLine ) ?
Aber das ist ja eigentlich noch ein harmloses Beispiel. Schlimm wird es dann, wenn man ganze Verwaltungsstrukturen aufbaut und vermeindlich optimiert, und dann am Ende der Flaschenhals ganz woanders sitzt.
Viele schlaue Leute haben es schon gesagt: Bring das Programm erstmal zum Laufen und lokalisiere dann die Problemstellen. Oder auch "Premature optimization is the root of all evil"
Natürlich sollte man schon ein Auge drauf haben, welcher Lösungsweg für die Situation der Beste ist. Nachträgliche Änderungen können auch viel Zeit kosten. Aber man darf sich nicht in Mikrooptimierung verlieren ("Diese Multiplikation kann ich auch mit Shift&Add umsetzen") und im Zweifel zwischen Optimierung und Aufwand (und man sollte oft zweifeln) den einfacheren Weg wählen.
Feature Overkill
Man hat gerade eine Klasse implementiert und denkt sich, dass die Klasse eigentlich auch noch ein paar andere Dinge machen könnte. Wenn man dann zurück blickt, stellt man fest, dass man nur seine Zeit damit verschwendet hat. Hier erweist sich das YAGNI Prinzip als hilfreich: You Aren't Gonna Need It. Ist eigentlich ein Prinzip aus eXtreme Programming, aber imo ein recht allgemein anwendbares. Erstmal alle Anforderungen erfüllen, sich nicht selbst neue Anforderungen (und damit Arbeit) schaffen. Das hält auch den Code kürzer, und weniger Code ist leichter wartbar.
Reinventing the Wheel
Damit fängt glaub ich jeder an. Aber das Problem ist ja nicht ein Anfänger, der mal selbst eine Linked List programmiert oder eine Vektorklasse implementiert. Eigentlich ist das auch ein Punkt, der mich weniger bei anderen stört, als bei mir selbst. Ich finde es einfach dann schade um die Zeit, wenn man etwas baut, und dann feststellt, dass es im Framework schon enthalten ist, wenn auch etwas abgewandelt. Oder dass es schon eine (oft freie) Bibliothek dafür gibt.
Umso schlimmer wenn man das mit Absicht macht, weil man anderen zu wenig zutraut, oder keine Lust (manche nennen das auch Inkompetenz) hat rauszufinden, wie man diese fremde Bibliothek benutzen soll.
Was haltet ihr für die häufigsten (tödlichen) Fehler in der Programmierung? Was nervt euch an Code und Programmen von anderen oder von euch selbst am meisten? Wobei der Schwerpunkt auf Fehlern trotz Wissen liegen sollte 😉 also nicht aus Unerfahrenheit oder Anfängerfehler 🙂 Vieleicht kann man ja noch etwas lernen.
e.f.q.
Aus Falschem folgt Beliebiges
An meinen Codes regt mich grundsätzlich auf das ich nichts kommentiere da wird so ein Code schon ziemlich schnell unübersichtlich und chaotisch, seit ich aber auf "goto" verzichte ist es nicht mehr ganz so schlimm.
Ich such noch mal ein projekt wo ich mich im Bereich KI üben kann
Ich kann Traumzauberer nur recht geben.
Ich habe lange Zeit Echtzeitsysteme gemacht, und dafür Jahre im Profiler
verbracht, und dabei dann immer wieder feststellen müssen, das der Flaschenhals
meist woanders war als vermutet.
Auch ändert er sich von Compilerversion zu Compilerversion.
Und zu Featureoverkill, das passiert meist schon bei der Auswahl der Komponenten
oder Algorythmen.
CAB braucht man nicht für eine Adresseingabe, oder das Truedbgrid zur
Darstellung einer Adressliste.
Das gegenteil ist aber auch manchmal der Fall.
Warum soll ich z.B. einen Kalendar implementieren, mit allen Tests usw.
wenn die ganzen grossen soetwas schon im angebot haben.
Aber am meisten nervt mich, wenn man eine Funktion nicht auf anhieb versteht
oder übersehen kann.
Dies kann auf unterschiedliche weise "passieren":
1.
Spagetticode, also routinen die deutlich mehr als 1 Bildschirmseite lang sind.
Das ist nie nötig.
2.
Zu lange Namen. Was nutzt mir ein Aussagekräftger name, wenn ich dadurch
ständig hin und her scrollen muss.
3.
Zuwenig Kommentare. Komplexe nicht auf den ersten blick erkenntliche
Problemlösungen sollten Kommentiert werden.
4.
Zuviel kommentare. Je mehr Text auf der Seite, um so unübersichtlicher wird es.
Siehe dazu auch meine Kommentare zu GhostDoc.
Aber auch mal Antipattern suchen, das ist manchmal auch interessant.
Hallo Traumzauberbaum
Original von Traumzauberbaum
Umso schlimmer wenn man das mit Absicht macht, weil man anderen zu wenig zutraut, oder keine Lust (manche nennen das auch Inkompetenz) hat rauszufinden, wie man diese fremde Bibliothek benutzen soll.
Ich glaube du hast hier einen wichtigen Punkt vergessen.
Es gibt praktisch für so ziemlich alles schon eine Lösung, aber es ist doch manchmal auch so, dass man nicht zu faul ist, sich in diese Lösungen einzudenken und auch nicht denkt dass diese Lösung schlecht ist.
Sondern man möchte alles von Grund auf selber machen, dies aus keinen deiner genannten Gründen, sondern dass man etwas geschafft hat und schliesslich auch die kleinsten Hintergründe versteht.
Ein nettes Beispiel.
Es gibt ja DirectX und es gibt auch viele, viele Engines, die man einfach so nutzen könnte.
Das Problem ist aber, dass man bei der Benutzung einer Engine viel weniger mit DirectX selber in Kontakt kommt und so auch die Hintergründe nicht wirklich verstehen kann.
In einem solchen Fall und mit der Motivation dass man wissen will, wie es funktioniert, halte ich das Neuerfinden des Rades für sinnvoll.
Gruss Peter
--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011
- https://peterbucher.ch/ - Meine persönliche Seite
- https://fpvspots.net/ - Spots für FPV Dronenflüge
Spagetticode, also routinen die deutlich mehr als 1 Bildschirmseite lang sind.
Das ist nie nötig.
Ich denke wenn man sich vorher überlegt hat was Die Routine machen soll ist das nicht mehr so problematisch da man ja im VS alle Routinen wie in einem Treeview einklappen kann.
Ich such noch mal ein projekt wo ich mich im Bereich KI üben kann
Den Kopf in den Sand zu stecken, um das Problem nicht sehen zu wollen,
ist natürlich auch ne Lösung.
Was mich besonders nervt:
1 Klasse für alles. Hört sich unglaublich an aber unter meinen Altersgenossen und die Leute aus meiner Klasse ist das sehr beliebt
Oder so tolle Variabelnamen wie "myDBConn1" "myDBConn2" "myLable2" "myBigLable33"...
die zwei Sachen erlebe ich sehr oft bei Leuten aus meiner Klasse und auch bei Lehrern, kann ich überhaupt nicht aushalten.
Weiterer Punkt: Inkonsistente Code Pattern. Mal sind die Methoden in der Kamelnotation, mal anderst, mal mit einem Verb am anfang, mal ist es nur ein Prefix. Das gleiche auch bei Instanzvariabeln etc.
Hoffe solche Sachen müsst ihr nie sehen! Sind wirklich Basics aber da ich es schon so oft gesehen habe, musste ich es einfach Niederschreiben. Sonst habt ihr ja bereits das Wichtigste genannt. Besonders Overkills sind böse 😉.
An meinem Code... hmmm... Vielleicht die miesen englischsprachigen Kommentare, Schreibfehler bei Variabeln weil ich einfach alles auf Englisch mache. Magische Zahlen, die ich öfters vergesse als Konstanten auszulagern oder noch weiter hoch...
Joa, Gruss,
Gregor
//Edit: Was schlimmes bei Andern vergessen: Sie schrieben Code den sie selbst nicht verstehen, sondern sich zusammengesucht haben übers Web, Bücher, etc. xD Das ist besonders schlimm wie ich finde 😁
hi folks,
wir haben uns hier immer mal wieder in ein paar fallen hineinmanövriert, die ich mal als Event Bouncing bezeichnen möchte:
Ein event löst ein event aus, das ein event auslöst, das ein event auslöst....
mit ein bisschen pech ist in der folgekette aller events das ursprüngliche event auch wieder mit drin und dann gibt´s ereignisbehandlungen bis zum sanktnimmerleinstag.... 🙂
wir halten es daher für sehr wichtig, sich vor dem codieren unbedingt gedanken über die ereignisarchitektur seiner klassen gedanken zu machen, denn die delegaten und ereignismöglichkeiten von .net laden zu allerlei tollen dingen ein, die man manchmal besser (sprich: auf direkterem prozeduralen weg) gelöst hätte.
gruß
ron
Zum Thema Optimierung muss noch der Dreizeiler hier genannt werden:
- Make it work
- Make it right
- Make it fast
=)
Ansonsten bin ich ebenfalls ein Verfechter des KISS Principles und halte wenig von Buzzword-Fetischisten (Wir muessen alles umbauen, das Internet ist jetzt in der Version 2.0..) und unueberlegter Benutzung von eben jener Hype-Technologien..
Edit: Furchtbar und total anstrengend sind auch Codebeispiele in der sog. "Hungarian Notation". Erstens wird der Grundgedanke der Notation von den meisten Leuten nicht begriffen (der Prefix soll nicht den Datentyp, sondern den Zweck/Inhalt beschreiben.. Geboren aus der Notwendigkeit z.B. in C unterschiedliche Variablen des gleichen Datentyps nicht versehentlich zu vermixen), zweitens ist er m.E. nach in C# und aehnlichen Umgebungen hinfaellig..
Pound for pound, plutonium is about as toxic as caffeine when eaten.
Hallo DarKlajid,
hm, also bei der Ungarischen Notation soll im Präfix schon der Typ angegeben werden. Um den Zweck anzugeben, gibt es ja den eigentlichen Namen.
Wie man an psz und ach sehen kann, ist die Differenzierung der Ungarischen Notation manchmal differenzierter und manchmal weniger differenziert als das C-Typsystem, aber das ist eher die Ausnahme.
Aber was du als Grund für die Entstehung (und entsprechend auch für den Wegfall in C#) der Ungarischen Notation siehst, kann ich nicht nachvollziehen. Das Problem mit der Ungarischen Notation ist vor allem, dass es soviele Typen gibt, dass man Massenhaft Typkürzel bräuchte und diese dann vermutlich auch deutlich länger sein müssten, um Namenskonflikte zu vermeiden.
herbivore
Kurz: Noe.
Lang: Von 1 ausgehend, ueber 2, 3 und 4:
Der gesamte Sinn der Notation ist ein vom Typ unabhaengiges/den Typ erweiterndes Konzept um Aepfel nicht mit Birnen zu vergleichen/verwechseln. Und dabei geht es eben nicht um den Datentyp. Das ein int ein int ist weiss ich selber und wenn ich das nicht auf Anhieb wiederkenne ist wohl eher meine Methode zu unuebersichtlich. Wenn ich aber eine Windowmessage mit einer Hintergrundfarbe vergleiche, nur weil beide auf einem Zahlentyp basieren, dann ist das in den meisten Faellen wohl ein Versehen und nicht zweckdienlich.
Damit ist also das Problem mit dieser Notation,
a) dass es allgemein gern missverstanden wird
b) dass wir in z.B. CSharp dafuer explizit Typen anlegen koennen (structs, Klassen..)
c) es einfach mehr als haesslich ist, in meiner kleinen Welt.
Der letzte/vierte Link ist zwar nicht komplett auf der "dieser i als Integerprefix Kram ist totaler Humbug" Linie, erklaert aber nochmals sehr schoen das Grundkonzept.
HTH,
Ben
Pound for pound, plutonium is about as toxic as caffeine when eaten.
Hallo DarKlajid,
Das ein int ein int ist weiss ich selber
woran? Daran, dass du auf die Deklaration guckst. Die Ungarische Notation ist genau dazu, um diesen Blick zu sparen.
herbivore
Mir faellt es gerade nicht leicht freundlich zu antworten. Hast du die Links ueberhaupt mal angesehen, oder bist du einfach der Meinung es unbegruendet besser zu wissen?
Im Moment wuerde ich gerne das BS-Wort rufen, dass man gerne in Meetings beim Bingo verwendet.. Anders: Weder der "Erfinder" der Notation noch die von mir zitierten Quellen sind der Meinung, dass man den Datentyp einer Variablen als Prefix nehmen sollte. Der Prefix ist eine Erweiterung (der bisher beste Begriff dafuer, den ich fand: Eine Annotation) des Typs.. Das ist etwas gaenzlich anderes, hat nichts mit iEineZahl und strEinString zu tun und macht im Gegensatz zu eben diesen Beispielen sogar Sinn. Manchmal. Wenn man halt nicht auf konkrete Datentypen ausweichen kann/will, s.o.
Ich bleibe dabei, dass jemand ein ernsthaftes Problem hat, wenn er nicht ohne Prefix den Datentyp seiner Variablen herausfindet.
Auf die Gefahr hin, dass du die am wenigsten verlaessliche Quelle am besten findest: http://en.wikipedia.org/wiki/Hungarian_notation spricht von zwei verschiedenen "Unternotationen", wobei deine Variante als "Systems Hungarian" bezeichnet wird. Der Artikel (und nein, ich hab den nicht gerade selbst verfasst) beschreibt aber auch korrekt woher diese Notation kommt und was der eigentliche Sinn davon ist/war - und das ist eben genau das was ich hier versuche zu erklaeren.
Pound for pound, plutonium is about as toxic as caffeine when eaten.
Hallo DarKlajid,
Entstehungsgeschichte hin oder her. Kennst du jemanden, der die Ungarische Notation im Sinne von Apps Hungarian einsetzt? Ich zumindest nicht und ich habe es noch nie irgendwo gesehen. Somit hast du zwar formal gesehen recht, praktisch gesehen ist es eher so, wie ich geschrieben habe. Ich freue mich, dass wir das jetzt auseinander dividiert bekommen und jeder auf seine Weise Recht hatte.
herbivore