Am Montag, 13. Dezember 2004 18:45, schrieb Eric Schaefer:
On Mon, 2004-12-13 at 12:19 +0100, Friedrich W. H. Kossebau wrote: #define für Konstanten und Makros sollte generell vermieden werden. Die Benutzung desselben ist ein guter Indikator für suboptimales Design.
Bzw. verwerfen den Vorteil der Typprüfung durch den Compiler bei C++. (Variante hatte ich auch nur für die C-Nutzer angeführt, natürlich ;)
Persönlich kapsele ich auch gerne einfache Datentypen in Strukturen oder Klassen (alternativ typedef, #define & Co.), denn ich finde if( Values.includes(Othervalue) ) lesbarer, weniger fehleranfällig und weniger nach Kommentar bittend als if( Value1 <= Othervalue && Value2 >= Othervalue ) Der Sinn lokaler Variablen wird auch schneller deutlich, wenn die Einheiten im Typnamen (mind. per typedef) eingearbeitet sind. Vergleiche FMeter Distance; und float Distance;
Meistens ist es auch so, daß die Werte andere Grenzen haben, als die eingebauten Datentypen. Über entsprechende Zugriffsmethoden kann man den Wertebereich prüfen und gegebenenfalls mit Exceptions um sich werfen.
Genau. :)
Wenn Du die Bedeutung einer Variablen erklären mußt, solltest Du den Namen der Variablen auch noch einmal überdenken.
In Zeiten von Copy&Paste sind abgekürzte Variablennamen (vom unvermeidbaren i mal abgesehen) sowieso Quatsch.
Kommt auf den Geltungsbereich an. "VariableIDidNotFindAShortAndPreciseNameFor" erschlägt dann vielleicht doch, wenn es nur 15-20 Zeilen Geltungsbereich sind, nehme ich gerne auch mal ne Abkürzung.
Aber vermutlich verlasse ich gerade das Thema Deiner Anfrage?
<AOL/>
Was bedeutet eigentlich dieses AOL? Gibt es irgendwo im Netz eine anerkannte Liste mit den gängigen Netz-Abkürzungen?
PS: "TODO" scheint ein anerkanntes Kennwort zu sein, das von vielen IDEs erkannt und deren nachfolgende Texte automatisch in eine Übersichtsliste extrahiert werden, z.B. // TODO: in eigene Funktion auslagern und mit X zusammenfassen
Mit IDEs kann man sehr viele produktivitätssteigernde Dinge anstellen, aber leider sind sie entweder auch nicht besser als vi+make oder sie sind umfangreich, bequem, schnarchlangsam und bloated. Außerdem sind die eingebauten Editoren meist eine Zumutung. Ich wollte mir neulich mal Anjuta antun, aber das erzeugt ja für ein Commandline-Executable-Projekt schon 40 Dateien und die lassen sich auch nicht mal eben so kompilieren. Den Fehler im Makefile kann man auch nicht ohne Kenntnisse von autoconf (oder was auch immer) beheben, denn es umfaßt schlappe 380 Zeilen. Die Entwickler von dem Teil müssen wirklich extremes Kraut rauchen...
Vielleicht klappte es mit dem Kompilieren deswegen nicht? ;)
Die Makefiles werden bei dem auto*-Krams übrigens aus kleineren Dateien (*.in & Co.) erzeugt, die sind dann schon übersichtlicher und handlicher (relativ). Wenn man dort mal reinschaut, kann man oft auch durch "Vergleichende Studien" Fehler beheben.
An und für sich sieht das Teil ja ganz nett aus, aber man müßte diesen autoconf-Mist abwählen können.
Bei KDevelop kann man sich das Makesystem mittlerweile aussuchen... :)
Gruß Friedrich