[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: e-mail verpasst wegen github



Hallo Freunde,

Sven Hartge schrieb:
Jochen van Geldern <dd8pz@imail.de> wrote:
Sven Hartge schrieb:
Was heißt hier "auskommentierter include's"?
/*
#include <stdio.h>
#include <stdlib.h>
...
*/

      
Nun in C ist das Kommentar-Zeichen normalerweise "/*" und Ende von
Kommentar "*/".
Alles was zwischen /* und */ steht sind Kommentare.
Das # am Zeilenanfang ist in C kein Kommentar sondern ein
Preprozessor-Befehl.
In C++ gibt es aber auch das "//" als Kommentar-Zeichen.
Mir bekannt. War nur aufgrund des Zitats nicht ersichtlich. Ich dachte,
er bezog sich auf die # vor include, was ja, wie du auch ausführst, zum
Präprozessor-Befehl dazu gehört und eben _kein_ Kommentar ist.

S°
Entschuldigung, dass ich mich unklar ausdrückte. Ich nahm an, dass man in meinem Text erkennen kann, das die 5 Präprozessorbefehle, die ich als 5 Inlude's bezeichnet habe, ja als solche Auskommentierungen nicht gemeint sind. ;-)

Ich hatte dieses aber als gutes Beispiel betrachtet, um auszudrücken was ich diesen äusserst schlecht finde.

Es ist unerheblich, ob der Code an sich Sinnvoll oder Unsinnig ist. Die Regeln eines leserlichen Code sollte auf jeden Fall berücksichtigt werden.

Auskommentierungen machen nur Sinn, wenn man in einer Testphase steckt in der gewisse Abläufe stillgelegt sein sollen. - z.B.
    1. weil in diese Daten anfgefordert werden die nicht verfügbar sind
    2. weil Verzweigungen zu Code ausgelöst wird, der noch nicht geschrieben ist bez. fehlerhaft ist.
    3. um nur eine direkte Funktion ohne Ballast zu testen bez. anderweitige Fehler auszuschliessen.

Nach diesen Phasen sollten alle Auskommentierungen entfernt sein! Ist Müll der nur irreführt, und den Code schwer leserlich macht.

Was ich in diesem Code aber besonders beanstande; und leider auch in vielen Beispielen, von Leuten wo man mehr erwarten dürfte, die ich sonst so zu sehen bekommen, ist die Tatsachen, das Variablennamen einfach nichtssagend sind!

Hier "mx" "cp" "px" "ppx"

noch trauriger aber "bios" "BIOS" "Bios"
1. fehlt hier jeglicher Kommentar  was es mit diesen Variablen auf sich hat.
2. sollte man einem Programmierer schlicht verbieten Gleichnamige Bezeichner in unterschiedlicher Schreibweise für verschiedenen Variablen anzulegen.
Zum Glück unterstützt C nicht auch noch Fett und Kursiv., als Diversifizierer...  :'(

und ganz daneben ist schliesslich "reset"! Dieser Begriff ist klar definiert und sollte nie zweckentfremdet werden.

Ich habe es mir zur Regel gemacht, dass ich in den Variablennamen immer den Typ mit einbeziehe.

BOOL = x...; INTEGER = i...; UNSIGNEINTEGER = ui... (8Bit us....); LONGINTEGER = li; REAL = r...; BYTE = b...WORD = w... u.s.w.

Das erleichtert es im Code immer zu erkennen welche Operationen mit einer Variablen überhaupt ausgeführt werden dürfen.

Einer Int.Var nur schon TRUE / FALSE zuzuweisen ist irr witzig! So erscheint ja der Eindruck es handle sich hier um eine BOOL.

Dazu kommt, dass es auch Prozessoren gibt, die mit TRUE in 16Bit oft "FFFF" übergeben; das sind insbesondere jene, die die Bit Abarbeitung direkt unterstützen; d.H. Bit-Befehle ohne ALU über Bit-Operator ausführen (grosser Zeitgewinn für Echtzeitverhalten, da Interrupt direkt zugreifbar). (Bei Intel nicht vorhanden)

Eine Schleife kann man schliesslich auch invers laufen lassen. Dabei setze ich zu Beginn den Zähler auf einen definierten Wert und dekrementiere bis "0"

hier also "mx--"

dann komme ich schon gar nicht in Versuchung einer Int TRUE zuzuweisen!


Gruss Marino



Reply to: