Hi. Ich programmiere seit Jahren meine µCs ausschliesslich in Assembler und bin auch ganz zufrieden damit. Mit ordentlichen Makros bekommt man eine sehr gute Lesbarkeit hin. C habe ich immer aus vielen Gründen gemieden. Die Lesbarkeit ist so grottenschlecht, dass ich im Dauerstrahl kotzen muss. Werden die Leute eigentlich nach Klammern bezahlt? Und dann die ganzen Bezeichner.... Unterstriche am Anfang wohin man schaut, und dann sogar noch doppelte Unterstriche??? Ernsthaft jetzt? Und am Ende des Bezeichners auch noch. WARUM? Soll das dann irgendwie ästhetischer wirken??? Naja, ich kapiere es nicht. Aber ich kann ja auch kein C. Vielleicht hat das ja ganz sachliche Gründe und die ganzen Wurschtler da sind gar nicht solche Idioten, wie es den Anschein hat. Kann ja sein. Wie dem auch sei, ich muss da jetzt ran. Also an C. Was ich allerdings weiss ist, dass die meisten Programmierer definitiv NICHT programmieren können. Nur weil ein Programm läuft, ist es noch lange nicht elegant und gut programmiert. Deshalb suche ich eine wirklich gute Quelle, wo ich sauberen C-Code lernen kann. Best practices mit Erklärungen, warum man das jetzt so macht und nicht anders. Das ganze als E-Book oder HTML-Seiten, aber keine nackte Referenz, denn da lernt man nicht das, was ich eben lernen will. Wo kann ich sowas finden?
:
Gesperrt durch Moderator
Jan, man könnte fast meinen, du möchtest mit deinem Beitrag eine TRoll-Diskussion starten. Jan schrieb: > Wie dem auch sei, ich muss da jetzt ran. Also an C. Wenn du doch Assembler liebst und C hasst, warum "musst du denn da jetzt ran" ?? Jan schrieb: > Nur weil ein Programm läuft, ist es noch > lange nicht elegant und gut programmiert. Deshalb suche ich eine > wirklich gute Quelle, wo ich sauberen C-Code lernen kann. Programmiere doch in C einfach so elegant und gut, wie du das bisher in Assembler machst. Schon ist alles prima.
:
Bearbeitet durch User
Vermeide C++ mit den typischen 10 wrapper classes um den code anderer
leute.
Die klammern und das einrücken erhöhen die lesbarkeit. Die {} klammern
kann man weglassen wo unnötig.
Unterteile funktionsblöcke mit leerzeilen. Kommentarzeilen sind auch
nicht schlecht.
Mach code der einigermassen läuft und nicht code der den ästhetischen
vorstellungen unfähiger leute genügt.
Sag mir das du alt bist ohne zu sagen das du alt bist.... Bei solchen Themen muss man sich nicht fragen, warum DE heute da steht wo es steht :))
_Unterstriche_ ... Das erinnert mich an Markdown-Textauszeichnung, die in Html eingebettet wird. Es scheint sich um einen Trick mit Zeichenkettenersetzung zu handeln (bei Markdown jedenfalls). Vielleicht kann man Unterstriche in C mit Unterstrichen in Markdown irgendwie mischen. In Bezug auf die viele Klammerung schadet C dem Finden neuer Ideen. Da müsste man die Ideen vorher aufschreiben und dann ohne zu denken in C codieren. Die Klammern in C sind (bei meinen Programmstücken) zu viel. Vielleicht mache ich was falsch. Funktionsargumente in Klammern: Es wird meistens eine Struktur also ein Datensatz von der Funktion bearbeitet. Falls man einige Zahlen in den Funktionsklammern übergibt ist das eine Täuschung, denn statt Gleichheit weist der Computer nur zu ":=".
a) ... Es ist etwas lang für den wenigen Nutztext!
static void myfunc (void)
{
puts("One more Daim."); // Daim ist ein Schokoriegel.
}
b) Braucht es endlich ein Zeilenfalt-Zeichen, das jeder Editor anbietet.
Zugegeben wieder eine neue Klammerung!
+ [ // Begin folded lines region.]
... ändert sich zu
- [ // Beginn folded lines region.
// In diesen Zeilen langer Text.
//
//
] // End region.
c) K. Zuse hat in der Sprache "Plankalkül" auch übereinander codiert.
Wie wäre es mit:
float_32 a = 1.0f, b = 0.0f, k = 0.2f; // Ortsvektor und
Drehgeschwindigkeit.
| a | | -b | // Der Vektor {a, b} wird um einen kleinen Winkelbetrag
| b | += k * | +a | // gedreht. Sein Radius muss noch korrigiert werden.
Jan schrieb: > Ich programmiere seit Jahren meine µCs ausschliesslich in Assembler und > bin auch ganz zufrieden damit. Mit ordentlichen Makros bekommt man eine > sehr gute Lesbarkeit hin. Das ist lustig, ich für meinen Teil versuche schon C zu meiden, weil es mir mühsam erscheint. Weil ich viele Unterfunktionen brauche um - wie du mit den Makros - etwas lesbar darzustellen. Aber das tut hier nichts zur Sache. Jede Sprache hat ihre Stärken und einen Anwendungsbereich. Imho das größte Risiko besteht darin, dass du wegen deiner guten Assembler-Kenntnisse C nur als Makro-Assembler nutzt. Ich habe ähnliches oft beim Umstieg von C zu höher abstrahierten Sprachen beobachten dürfen: Dass die neue Sprache im Stil der alten benutzt wurde. Ein C-Programmierer kann in jeder Sprache C programmieren. Genau so lässt sich assemblerartig C programmieren. Die sprachspezifischen Vorteile bleiben so oft ungenutzt. C hat zusätzlich das Problem, dass du als Assember-Programmierer glaubst, genau zu wissen, was passiert, C dir dies aber nicht garantiert. Ich möchte das an einem konkreten Beispiel verdeutlichen: Als Assembler-Programmierer weist du, wie ADD mit 2er-Komplement-Werten überläuft, d.h. das Ergbenis ist ggf. negativ, zusätzlich werden Flags wie der Two’s complement overflow indicator gesetzt. Die Gefahr ist, dieses Wissen zu übertragen und anzunehmen, eine signed-Variable verhalte sich genauso. Tatsächlich ist der Signed-Overflow in C undefined behaviour. Der Compiler darf davon ausgehen, dass der Programmierer das nicht nutzt und ggf. Optimierungen vornehmen. Praktisch liegt man oft richtig, weil das oft mit ADD übersetzt wird. (Empfehlung: godbolt.org). So entsteht aber nicht portierbarer C-Code, der auf einer anderen Platform, einem anderen Compiler oder auch nur anderen Switches u.U. nicht mehr funktioniert. Ich empfehle daher ein Buch, das präzise ist und auf diese Feinheiten eingeht:
1 | Robert C. Seacord |
2 | Effective C: An Introduction to Professional C Programming |
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten