Hi ich wollte bei mein Arbeitgeber ein Coding guideline einführen. So Bezüglich variable naming , header template und co.... Da muss man ja das Rad nicht neu erfinden ;-) Kann jnd da was empfehlen?
@Rufus Τ. Firefly (rufus) (Moderator)
>MISRA?
Ist das aber nicht eher für die meisten Leute Overkill?
Und wenn es angewendet wird, dann meist mit verdammt vielen Ausnahmen.
;-)
:
Bearbeitet durch User
Wieviel Programmierer seit ihr denn im Team? Programmierer sind oft recht eigensinnig, da muß man erstmal versuchen, sich untereinander zu einigen. MISRA mag ich auch nicht. Viele Regeln sind eindeutig für absolute Anfänger gedacht und behindern den erfahrenen Programmierer.
Vermutlich gibt es etwa so viele Programmierregelstandards wie C-Programmierer. Zwar habe ich MISRA vorgeschlagen, aber --natürlich-- wende ich es selbst nicht an, dazu hat sich mein selbsterarbeiteter Stil viel zu sehr in der Gehirnrinde festgefressen (ich mach' das zum Geldverdienen schon seit über einem Vierteljahrhundert). Wie war das? Alte Hunde, neue Tricks?
Ja, die Ausnahmen... Was spricht dagegen, MISRA als Basis zu nehmen und einen eigenen Subset zu definieren, dann kann man auf fertige Produkte zum Check zurückgreifen, wenn gewünscht. Ansonsten gibt der Linux-Kernel-Coding-Style einige sinnvolle Anregungen: https://www.kernel.org/doc/html/v4.10/process/coding-style.html z.B. warum ist das Einrücken durch Tabs sinnvoll:
1 | Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3. |
2 | |
3 | Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you’ve been looking at your screen for 20 straight hours, you’ll find it a lot easier to see how the indentation works if you have large indentations. |
4 | |
5 | Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program. |
6 | |
7 | In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning. |
Ciao, Martin
H. R. schrieb: > Hi > ich wollte bei mein Arbeitgeber ein Coding guideline einführen. So > Bezüglich variable naming , header template und co.... Das ist ja schön und gut, aber wenn du schon die Möglichkeit hast, was einzuführen, dann fange doch am besten mit gutem Code an. Wenn du die Leute dafür sensibilisierst guten Code zu schreiben, dann sind solche Sachen wie Namenskonventionen nur noch Schmuck am Nachthemd. > Kann jnd da was empfehlen? "Clean Code" Reihe von Robert C. Martin. Ich würde das zur Pflichtlektüre für jeden Programmierer im Team machen.
H. R. schrieb: > ich wollte bei mein Arbeitgeber ein Coding guideline einführen. So > Bezüglich variable naming , header template und co.... > Da muss man ja das Rad nicht neu erfinden ;-) > Kann jnd da was empfehlen? Wenn es um solche Formalismen geht, dann fang mit etwas wie GNU Coding Standards an https://www.gnu.org/prep/standards/ oder Indian Hill (modifiziert) an http://www.doc.ic.ac.uk/lab/cplus/cstyle.html und werf alles raus was für Embedded nicht passt. Für Kommentare würde ich noch eine Formatierung / Markup wie Doxygen hinzu nehmen.
Z.b. damit verbinden, eine statische Codeanalyse mit lint o.ä. im Zuge des Entwicklungsprozesses zu verbinden. Gehört imho auch da rein.
Peter D. schrieb: > MISRA mag ich auch nicht. Viele Regeln sind eindeutig für absolute > Anfänger gedacht und behindern den erfahrenen Programmierer. Das sollte man in "famous last words" aufnehmen ;) Oliver
Falk B. schrieb: (MISRA) > Und wenn es angewendet wird, dann meist mit verdammt vielen Ausnahmen. So ist das ja auch gedacht. Man kann gegen die Regeln verstoßen, muß aber technisch begründen, wieso es erstens sicher ist und zweitens die richtige Wahl. Die natürliche Faulheit der Programmierer führt dazu, daß das dann nicht wahllos gemacht wird, und wenn, daß man drüberblickt.
Martin H. schrieb: > The answer to that is that if you need > more than 3 levels of indentation, you’re screwed anyway, and should fix > your program. Die Folge: jede Funktion wird in zig weitere gesplittet, und zwar auch ohne daß es dabei um wiederverwendbare Codestücke geht. Lesbarer ist das nicht.
Nop schrieb: > Martin H. schrieb: > >> The answer to that is that if you need >> more than 3 levels of indentation, you’re screwed anyway, and should fix >> your program. > > Die Folge: jede Funktion wird in zig weitere gesplittet, und zwar auch > ohne daß es dabei um wiederverwendbare Codestücke geht. Lesbarer ist das > nicht. Man splittet Funktionen nicht nur auf um Code wiederzuverwenden, sondern auch um die Lesbarkeit zu erhöhen. Die Lesbarkeit leidet unter riesigen Funktionen. Wichtig ist aber nicht die reine Länge, sondern der Zweck: Kannst du den Zweck einer Funktion nicht in einem Satz beschreiben dann ist aufspalten in kleinere logischen Einheiten sowieso angeraten.
Cyblord -. schrieb: > Man splittet Funktionen nicht nur auf um Code wiederzuverwenden, sondern > auch um die Lesbarkeit zu erhöhen. Die Lesbarkeit leidet unter riesigen > Funktionen. Wenn man zig Mini-Codeschnipsel hat, bloß um nicht mehr als 3 Level einzurücken, leidet die Lesbarkeit genauso. Das wird dann zu Lasagne.
Nop schrieb: > Wenn man zig Mini-Codeschnipsel hat, bloß um nicht mehr als 3 Level > einzurücken, leidet die Lesbarkeit genauso. Das wird dann zu Lasagne. Max 3 Level mag übertrieben sein und irgendwann sind extreme Verschachtelungen auch der Performance abträglich, aber warum leidet die Lesbarkeit darunter? Wenn im Extremfall eine Funktion so aussieht:
1 | void bla() { |
2 | macheWas(); |
3 | macheWasAnderes(); |
4 | TueSchlimmes(); |
5 | NochMalWas(); |
6 | }
|
sieht man auf den ersten Blick was sie tut (falls die Funktionsnamen sinnvoll gewählt sind). Will man Details springt man in die jeweilige Funktion die einen interessiert.
:
Bearbeitet durch User
Cyblord -. schrieb: > Max 3 Level mag übertrieben sein und irgendwann sind extreme > Verschachtelungen auch der Performance abträglich, aber warum leidet die > Lesbarkeit darunter? Weil die Top-Funktion lesbarer wird, aber wenn man dann wirklich wissen will, wo genau was berechnet / gesetzt wird, ist das nicht mehr so offensichtlich. Es ist OK, Funktionen aufzuteilen, wenn man ansonsten in der Funktion einen Kommentar setze würde wie "und hier geht jetzt der Abschnitt mit Bla los". Das ist inhaltliche Aufteilung. Aber nur um Einrückungslevel zu sparen, weil man mit Tab=8 einückt und es sonst nicht auf den Bildschirm paßt?! Nee danke. Wobei ich hier nicht Sachen wie verschachtelte Zustandsmaschinen rechtfertigen will, die in jedem case der oberen nochmal ein switch der unteren aufbaut.
H. R. schrieb: > ich wollte bei mein Arbeitgeber ein Coding guideline einführen. Entweder hast Du zuviel Zeit, zuviel Macht oder zuwenig Erfahrung. Vergiss es. Gibt nur böses Blut. Führe erst mal für Dich eins ein. Erst dann kannst du die verschiedenen Guidelines verstehen und warum sie was empfehlen. Und bewerten, ob es für Dich passt. Und dann versuche den Geist der Codebasis zu erkennen und zu verstehen, warum er sich so entwickelt hat. 3,4 oder 8er Tabs haben ihre vor und Nachteile und weitere Auswirkungen auf den Codierstil. Erkenne Euren Default und ändere ihn nur, wenn es einen guten Grund gibt. Benamung: Es gibt einige erprobte Standards (z.B. per #define angelegte Konstanten in Großbuchstaben). Aber meist schießt man ganz schnell übers Ziel hinaus und erschafft Wortmonster die nicht lesbar sind. Wir haben viele kleine Treiber, die Kraut und Rüben programmiert sind. Bei 1000 oder 10.000 Zeilen lohnt sich aber auch kein Prinzipienkrieg. Bei einer 1Mio-Applikation hat sich über die Jahre eine ganz ausdifferenziert Namenskonvention entwickelt, die so intiuitiv ist, dass sie von allen übernommen wird. Kümmere Dich um Lint, Misra und um die Versionskontrolle. Und finde ein einfaches und minimales Regelwerk, dass nicht unnötig mit dem bisherigen Geist bricht. Peter D. schrieb: > Viele Regeln sind eindeutig für absolute > Anfänger gedacht und behindern den erfahrenen Programmierer Sehe ich genauso. Sobald ein Projekt größer wird (>> 20kLoC) passen "Hallo-Welt"-Regeln einfach nicht mehr.
H. R. schrieb: > ich wollte bei mein Arbeitgeber ein Coding guideline einführen. So > Bezüglich variable naming , header template und co.... > Da muss man ja das Rad nicht neu erfinden Doch du sollst einen style definieren der für deine Firma passt. was ist so schwer daran ein paar codestyle regel aufzustellen zu der man eine persönliche Meinung und eigene Erfahrung hat?! Stupides Übernehmen von Regeln aus einem anderen Coder-Kulturkreis muss doch zwangsläufig zur Ablehnung wegen praxisfremd führen. Man sollte daher nicht nach wo anders erfundenen 1:1 regeln kopieren, weil das ja zum "cargo cult programming" Antipattern führt. https://en.wikipedia.org/wiki/Cargo_cult_programming
MISRA macht m.W. nur wenige Aussagen zu > variable naming und überhaupt keine zu > header template Wenn es bei den Kodierrichtlinien hauptsächlich um das äußere Erscheinungsbild geht, würde ich mich – wie von Jack schon vorgeschlagen – an die Richtlinien von größeren Open-Source-Projekten (wie bspw. GNU) anlehnen. Solche Richtlinien sorgen i.Allg. dafür, dass der Quellcode "wie aus einem Guss" aussieht, gängeln aber im Gegensatz zu MISRA die Entwickler kaum, so dass sie von diesen leichter akzeptiert werden. Welche Informationen den Header-Templates enthalten sin sollen, muss man firmenintern entscheiden, da sich darin u.a. der in der Firma angewandte Entwicklungsprozess widerspiegelt. In manchen Firmen wird hier bspw. die Änderungshistorie mit aufgenommen, was aber nur dann notwendig und sinnvoll ist, wenn keine toolbasierte Versionsverwaltung gepflegt wird. Anderes Beispiel: Ein Copyright-Vermerk ist nur dann erforderlich, wenn der Quellcode an Kunden oder an die Öffentlichkeit weitergegeben wird.
Rufus Τ. F. schrieb: > aber --natürlich-- > wende ich es selbst nicht an, dazu hat sich mein selbsterarbeiteter Stil > viel zu sehr in der Gehirnrinde festgefressen Rufus Τ. F. schrieb: > Wie war das? > Alte Hunde, neue Tricks? https://www.hunde-aktuell.de/thema/einem-alten-hund-neue-tricks-beibringen.27402/ Wenn du das selbe Verhalten an den Tag legst, dann mach ich mir um deine Zukunft richtig sorgen. (... sorgen und entsorgen da ist nicht mehr viel dazwischen ;-)
Viel wichtiger als eine gute Vorlage für soetwas finde ich die Akzeptanz im Team. Da könnte es hilfreich sein, diese Themen mal in einem Workshop gemeinsam zu erarbeiten und dort die Guidelines von dem Team aufstellen zu lassen. Dann jeweils Codereview von einem anderen Programmierer. Sonst macht sowieso jeder was er will. :-)
Je erfahrener der Programmierer, umso weniger diskutiert er um solche Details und toleriert, was ihm vorgesetzt wird. Coding Style Regeln sind ein nettes Spielzeug, mit dem sich Anfänger und Manager die Zeit vertreiben. Bei einer Firma haben 10 Leute stundenlang über die maximale Zeilenlänge diskutiert, als ob das Heil der Welt davon abhängen würde. Sicher gibt es Dinge, die man machen soll und welche die man nicht machen soll. Erfahrene Entwickler wenden die allgemein üblichen Regeln auf angemessene Weise an. Unerfahrene bekommen es von ihren Senior Kollegen nach und nach beigebracht. Ein schriftliches Regelwerk halte ich für wenig hilfreich. Da diskutiert man am Ende viel zu viel über mögliche Ausnahmen und über die feinen Unterschiede zwischen "kann", "soll" und "muss". Bei meinem aktuellen Arbeitsplatz gibt es ein regelwerk, daß die Struktur und Style von Java Programmen festlegt. Es umfasst nur eine Din-A4 Seite, und 90% von dem was da drin steht, ist ohnehin selbstverständlich. Wenn man sich eine neue Java Klasse anschaut, erkennt man bei uns schon am Stil direkt, wer der Autor war. Jeder macht es etwas anders und das ist so Ok. Toleranz halte ich für wichtiger, als harte Regeln die einen später unnötig einengen. > Viel wichtiger als eine gute Vorlage für so etwas finde ich die > Akzeptanz im Team. Ja absolut. Anstatt zu versuchen, ein umfassendes Regelwerk zu erstellen würde ich den umgekehrten Weg gehen. Tragt zusammen, was am schlimmsten nervt und macht nur dafür (bzw. dagegen) Regeln.
Stefan U. schrieb: > Ja absolut. Anstatt zu versuchen, ein umfassendes Regelwerk zu erstellen > würde ich den umgekehrten Weg gehen. Tragt zusammen, was am schlimmsten > nervt und macht nur dafür (bzw. dagegen) Regeln. Regel 1 - lex kurt gödel - Regeln stören die Creativität und werden daher verboten. SCNR
Was hast du den dir bei speziellenen Embedded Code style gedacht? Was ist bei Embedded also C auf µC/FPGA so anders als beim PC/Smartphone C ? Eigentlich nur die HAL. Was muss man bei der HAL anders machen als bei GUI/App/database/...-Code? -vielleicht im fileheader immer die platform (controller) mit Eckdaten Takt/Speicher nennen? -ebenso Compiler mit Rev und Library und controllerspez. Optionen -Namensgleichheit zu anderen Unterlagen (Schaltplan/FPGA-HDL-Code/Datenplatt_controller) bei Variablen/pin-signalen/embedded_peripherals einfordern -spezielle Richtlinien für ISR-Code festhalten -typen verwenden bei der die bitlänge klar ist bspw. uint8 -nach compilierung für die Ressorcenüberwachung Codegröße/RAM-bedarf mitloggen- -Festleggungen zu Zahlenbereichen von Error-code -Vereinbarungen zur Emulation externer Inputs beim Debugging, -HiL-Schnittstelle (beispielsweise LabView/CVI) beachten Programmiert man C für ein FPGA-SoC sind IMHO auch Überlegung hinsichtlich der Verzahnung FPGA-HDL Toolchain und Firmware-C-Compiler nötig: -Festlegung hinsichtlichen Übernahme von generireten code aus Fremdtools beispielsweise die systemgeneratoren von FPGA-SoC-Systemen schmeissen ne Menge raus. -Scripte erstellen die aus HDL-code C-Header generieren (bspw Adress Maps) ...
Du kannst einen Coding-Style grob in die folgenden Teile unterteilen: - Formatierregeln - Dokumentationsregeln - Code-Konstrukte und Sprachfeatures - Namensregeln - Physisches Layout Formatierregeln: Unbedingt etwas gängiges nehmen, z.B. 1TBS. Dazu liefert man eine Tool-Konfiguration, z.B. Parameter für indent und Einstellungen für Eclipse oder der aktuellen Mode-IDE. Dokumentationsregeln: Templates für .c und .h Dateien. So viel wie möglich Tool-Unterstützt. D.h. New->File Templates für Eclipse. Versionskontrolle zum Einfügen von Versionsnummern etc. (wenn benötigt). Klarer Satz von Markups. Code-Konstrukte und Sprachfeatures: Hier wird es schwiering. Schreibt man Trivialitäten auf? Einen Dummen gibt es immer ... Was erlaubt und verbietet man? Wenn man Leute im Team hat, die sich bei ?: in die Hose scheißen, wird es schwierig. Am anderen Ende, wenn man Leute hat die Trigraphs verwenden sollte man statt einem Codingstyle ein Erschießungskommando besorgen. Auch hier ist Toolunterstützung angesagt, z.B. lint. Namensregeln: Alles außer Hungarian Notation ist diskutabel. Strengere Regeln für externe Funktionen und Variablen (kurzer Modulnamen-Prefix, einheitliche Funktionsstruktur, ...), weniger strenge für static und lokale. Physisches Layout: Hängt bei C sehr stark mit Modularisierung zusammen. Vielleicht das Team separat schulen wie man C-Code modular aufbaut. Den Chef-Architekten mit dem Aufbau und der ständigen Verfeinern der Modulstruktur und der Überwachung des physischen Layouts betrauen (hier kenne ich kein Tool), dann muss man nicht so viel in den Guide schreiben. Wenn man es schafft jeden Teil auf einer Seite abzuhandeln hat man eine vernünftige Größe für den Guide. Bei den Regeln kann man unterscheiden was unbedingt muss, normalerweise muss, was sollte, was noch akzeptabel ist und was nicht geduldet wird. Allgemein gilt die Grundregel, wenn man keine Möglichkeit hat Regeln durchzusetzen kann man sich das Aufstellen von Regeln sparen. "Speak softly, and carry a big stick." Theodore Roosevelt
Auf den ersten Blick sieht https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard einigermaßen sinnvoll aus.
Hermann M. schrieb: > Auf den ersten Blick sieht > https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard > einigermaßen sinnvoll aus. Hm, a bisserl unaufgeräumt das ganze, irgendwie hat man den Eindruck, man müße es erst kaufen, aber dann finden sich dann doch ein paar regeln. Die: https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard/Procedure-Rules/Interrupt-Functions scheint mir recht vernünftig aber auch etwas zu knapp.
In Büchern wie "Clean Code" oder "Weniger schlecht programmieren" wird größte Wert auf die "Lesbarkeit" des Codes gelegt. Und zwar deshalb, weil Code mehr gelesen als geschrieben wird. Will sagen: Code entwickelt sich über die Zeit weiter und muss deshalb sehr gut verständlich sein und nicht nur einfach irgendwie "funktionieren". Und da ist es ein wenig wie bei den Schriftstellern: Nicht jeder hat das Zeug dazu, einen leicht und gut lesbaren Bestseller zu schreiben, den man nicht mehr aus der Hand legen will. Man kann den Leuten aber raten: "schreibt gute Bücher, ähh.. Code, den jeder gern lesen will ).
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.