Hallo, auch auf die Gefahr hin hier gleich ausgelacht zu werden. Gibt es gute Literatur fuer uebersichlichen guten Code, gerade fuer Zeitkritische Dinge, die in C geschrieben werden? Ich haette gern eine Art Uebersicht, wo drinn steht, was man evt. meiden sollte oder was gut ware. Ich meine man kann etwa alles global definieren und in Funktionen stecken oder alles ueber Merker machen, was beides wohl nicht sonderlich sinnvoll ist, gerade bei grossen Projekten. Ich denke dabei auch an Grundlagen die aussagen, wie man vorgehen sollte, damit der Code effizient bleibt bei mehr uebersicht. Diesbezuegliche Informationen zu anderen Sprachen, wie c++ oder Assembler wuerden mich auch interesseren. Gruss Marc
Das kann man am besten lernen, wenn man sich zehn Jahre damit beschäftigt. Fang schonmal an. Auf deinem Weg werden dir dann jede Menge schlechte und gute Programmierstile begegnen und du kannst selber abwägen.
"Clean Code: A Handbook of Agile Software Craftsmanship" http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1331829962&sr=8-1
Neben dem Codingstyle sollte man auch die Antipatterns (http://www.little-idiot.de/teambuilding/AntiPatternSoftwareentwicklung.pdf) im Auge behalten ;-)
Eine Möglichkeit wäre, du nimmst ein Open-Source Projekt, in dem wenige Leute Unmögliches realisiert haben. Wenn jemand ein Buch schreibt, weißt du nicht, ob er wirklich Ahnung von gutem Programmierstiel hat. Wenn ein paar Leute überzeugenderes zustande bringen als ein ganzer Konzern, müssen sie Ahnung davon haben. Linus Torvalds sagte mal ganz lapidar. Der Code ist zwar 100 mal so groß, aber der Aufwand einer Änderung ist gleich geblieben. Wenn du guten Programmierstil lernen willst, musst du dir anschauen, wie solche Leute ihren Code anlegen.
Thomas Klima schrieb: > Neben dem Codingstyle sollte man auch die Antipatterns > (http://www.little-idiot.de/teambuilding/AntiPatternSoftwareentwicklung.pdf) >> "Anti-Patterns im Projektmanagement" 100% Déjà-vu
> Gibt es gute Literatur fuer uebersichlichen guten Code
Literatur ist schon mal schlecht.
Denn wer Zeit hatte, ein Buch zu schreiben, der ist nicht gut.
Auch gibt es viele Theoretiker, die nie ein grosses Programm erstellt
haben, aber meinen, sich als Klugschwätzer hervortun zu müssen.
So nach dem Prinzip:
Ich diktier euch Arbeit, denn ihr seid meine Sklaven.
Daher ist das ein komplett falscher Ansatz.
Man schaut besser in den Code bekannt erfolgreicher Software, die in
deiner Sprache zu deinem Thema passt.
Da gibt es viel Auswahl, weil inzwischen einiges öffentlich ist, wer
sich für Betriebssysteme interessiert kann nicht nur in Lunux gucken,
sondern auch CP/M+GEM und WindowsNT sind inzwischen bekannt.
Und wer nicht den Mut hat, mal nachzusehen wie es erfolgreiche andere
machten, der sollte erst gar nicht anfangen..
Marc schrieb: > Gibt es > gute Literatur fuer uebersichlichen guten Code, gerade fuer > Zeitkritische Dinge, die in C geschrieben werden? nein. Stattdessen rate ich dir, selbständig nachzudenken und nicht irgendwelche Guru-Sprüche zum privaten Evangelium zu erheben. Gerade in der Schlampersprache C gibt es davon ne Menge und auch deses Forum ist voll von Beiträgen, aus denen man sehen kann, daß da Eleven nicht gebildet wurden sondern dressiert wurden und somit irgendwelche bescheuerten Maximen lebenslang mit sich herumschleppen, nach dem Motto "So macht man das eben". Mein 1. Rat: Schreibe deine Quelltexte so, daß du rein optisch beim Ansehen des Textes die Strukturen sehen kannst. Der Mensch ist ein "Augentier" und da hilft es sehr, wenn Quellen nicht wie Kraut und Rüben aussehen. Mein 2. Rat: Schau über den Tellerrand. Gerade die Einfältigeren unter den Programmierern kennen nur "ihre" Programmiersprache (was im Moment zumeist C ist) und schauen verächtlich auf alles Andere. Schau dir also besser auch Pascal und ein neueres Basic oder ein Python an. Nicht daß ich die jetzt alle loben will, aber es sind andere Programmiersprachen, die auch andere Vorzüge haben und zumeist in einem anderen Stil geschrieben sind als das von dir erwähnte C. So lernst du, daß es auch anderes gibt und wenn du dich auch damit befaßt, dann bekommst du ein Gefühl dafür, wie guter und wie eher schlechter Stil aussieht. Sowas ist nämlich nach meiner Erfahrung einigermaßen systemübergreifend und ein guter Stil ist nicht abhängig von einer bestimmten Programmiersprache. Mein 3. Rat: Denke lieber selber über Sinnfälligkeiten nach, als daß du Gewohnheiten Anderer einfach so übernimmst. Wir hatten schon zuvor hier Diskussionen über soche Dinge wie: while(1) { blabla }; was man noch übertreffen kann mit #ifdef xyz #define lala 1 #endif ... ne Menge Code ... while(lala) { blabla }; Ein praktisches Beispiel ist ChaN's FAT-Filesystem, wo man fast alle "genialen" Arten schlechten Codes drin findet. Ein weiteres sehr ansehnliches Beispiel ist die ST-Library zu deren ARM/Cortex-Controllern. Da wird der schlechte Programmierstil auf die Spitze getrieben: Man erstickt in Tausenden überflüssiger Konstantendeklarationen, die einzeln in umfänglichen struct's an die jeweiligen Funktionen übergeben werden, um dort schlußendlich einfach nur zusammengeklatscht zu werden. Und: Es gibt hier sogar Programmierer, die diese ST-Lib ganz toll finden. Das sind die, die das eigene Denken nie erlernt haben und stattdessen von den andressierten Maximen leben. Letzter Rat: Selber denken und nochmals selber denken. W.S.
Danke erst mal an die ganzen Antworen. Ich arbeite im uebrigen zum grossen Teil mit den ST-Libs wenn ich mich an einem STM32 Vergreife. Dort habe ich eine kostenlose Version von Atollig genutzt, was mich vorerst zwangsweise auf C gebracht hat. Wahrscheinlich ist es wirklich das beste sich bestehende Projekte anzusehen. Allerdings wollte ich das parallel oder nach dem ersten Einlesen in entsprechende Literatur vornehmen. Als Literatur wuerde ich mich nicht nur auf Buecher versteifen, sondern auch gute Threads. Ich moechte halt vermeiden mir Dinge anzueignen die super lesbar sind, bei denen ich aber nach einer gewissen Zeit feststellen muss dass sie am Ende unnoetig Rechenzeit fressen oder doch wieder Unordnung bringen. 10 Jahre bockmist fabrizieren wollte ich jedoch auch nicht^^. Nachdem ich die ersten Buchbewertungen gesehen habe werde ich wohl doch primiar auf bestehenden Code gehen. Gruss Marc
> die super lesbar sind ... am Ende unnoetig Rechenzeit fressen
Da brauchst du keine Angst haben. Was super lesbar ist, lässt sich
schnell und einfach umbauen.
Am meisten Geschwindigkeit bekommst du, wenn du unnötige Arbeitsschritte
vermeidest - dafür brauchst du Lesbarkeit.
MaWin schrieb: >> Gibt es gute Literatur fuer uebersichlichen guten Code > > Literatur ist schon mal schlecht. > > Denn wer Zeit hatte, ein Buch zu schreiben, der ist nicht gut. Das kann man so nicht stehen lassen. Es gibt unzählige exzellente Bücher auf dieser Welt, die nach dieser Logik unmöglich wären. > Man schaut besser in den Code bekannt erfolgreicher Software, die in > deiner Sprache zu deinem Thema passt. Guten Code zu sehen ist auf jeden Fall wertvoll, ich hatte da auch schon mal einen "Augenöffner" vor mir. Was bei gutem Code aber nicht dabei steht ist warum er gut ist. Man kann den Code studieren, aber vieles erschließt sich einfacher wenn man explizit darauf hingewiesen wird. Da kann Literatur sehr wertvoll sein. Das ist so ähnlich wie der Unterschied zwischen einem Mentor und jemanden der einem einfach nur bei der Arbeit zusehen lässt. Gruß Reinhard
Reinhard R. schrieb: > MaWin schrieb: >>> Gibt es gute Literatur fuer uebersichlichen guten Code >> >> Literatur ist schon mal schlecht. >> >> Denn wer Zeit hatte, ein Buch zu schreiben, der ist nicht gut. > > Das kann man so nicht stehen lassen. Es gibt unzählige exzellente Bücher > auf dieser Welt, die nach dieser Logik unmöglich wären. unterstreich
Kein Name schrieb: > Da brauchst du keine Angst haben. Was super lesbar ist, lässt sich > schnell und einfach umbauen. > > Am meisten Geschwindigkeit bekommst du, wenn du unnötige Arbeitsschritte > vermeidest - dafür brauchst du Lesbarkeit. Das ist sicherlich nicht allgemeingültig. Ich möchte niemanden dazu auffordern unleserlichen Quellcode zu produzieren, aber es gibt eben auch Fälle in welchen man mit trickreichen Anweisungen effizienter zum Ziel kommt - zumindest aus Sicht der Laufzeit. Nicht unbedingt sofort lesbar und empfehlenswert, aber manchmal muss man eben abwägen. Überhaupt halte ich die Einstellung zur Literatur hier für sehr problematisch. Klar ist nicht jedes Buch zum Thema Software Engineering und Coding Style brauchbar, aber es gibt doch ein paar sehr gute (!) Bücher von Autoren, die im Laufe ihrer Karriere sicherlich mehr Praxiserfahrung gesammelt haben als die meisten hier. Auch wenn ich absolut kein Freund von Pauschalisierungen bin, denke ich, dass das Problem darin liegt, dass viele hier eben sehr nah an der Hardware arbeiten. Und das meistens in C (bzw. Assembler), während "echte" Software-Architekten heutzutage - so behaupte ich zumindest einmal - wohl in den meisten Fällen mit objektorientierten Sprachen arbeiten und modellieren. Viele etablierte Konstrukte des Software Engineerings (Architekturmuster, Entwurfsmuster, etc.) machen dahin gegen in C (bzw. Assembler) entweder gar keinen Sinn oder lassen sich, wenn überhaupt, nur krückenhaft nachbauen. Jedenfalls weiß jemand der mit der objektorientierten Programmierung umzugehen in der Lage ist (und an größeren Projekten beteiligt ist), jegliche professionelle Hilfe in Form von Designvorschlägen zu schätzen. Viele dieser Vorschläge entstammen ja den eigenen negativen Erfahrungen, die man im Laufe der Zeit halt so gesammelt hat. Dennoch lassen sich einige Dinge (richtige Strukturierung, richtige Kommentierung, richtige Variablen- und Funktionsbenennung, richtige Dokumentierung, die Verwendung der richtigen Werkzeuge für einen optimalen Workflow wie auch das ein oder andere abstraktere Konzept) in die eigene Welt übertragen. Schaden tut das ganz bestimmt nicht. Und wie schon gesagt, solange man nicht explizit gesagt bekommt worauf es zu achten gilt, übersieht man "guten" Code halt auch leicht. Vor allem aber weiß man unter Umständen guten von schlechten Quellcode gar nicht zu unterscheiden. Überhaupt ist das Lesen von Quellcode eine Kunst (bzw. ein Handwerk) für sich. Unter diesen Gesichtspunkten sehr zu empfehlen ist z.B. "The Pragmatic Programmer" von "Andrew Hunt" und "David Thomas". Auf Amazon.de findet man dann auch entsprechende Empfehlungen, die sicherlich auch brauchbar sind. Insofern sollten einige "Praktiker" hier vielleicht ihre Meinung über die "nichtsnutzigen Theoretiker" nochmals überdenken. Ein guter Handwerker (und dazu zähle ich einen Programmierer in gewissen Maße) muss beide "Ansätze" beherzigen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.