Ich weiß, das ist jetzt ein etwas kontroverseres Thema, aber gut; angesprochen werden sollte es trotzdem einmal - und sei es (nur) aus aktuellem Anlass bei mir

Derzeit bin ich im Praktikum bei $Firma, und da gibt es eine Code-Richtlinie, nur keiner hält sich wirklich dran. Der Quälkot sieht manchmal richtig grausam aus, obwohl selbst schon die derzeitige Richtlinie normal für einen besseren Codestil reichen würde. Neben einer Reihe von Regelungen, die Optional sind (und weder in der einen, noch der anderen Auslegung verwendet werden), gibt es zahlreiche Regeln des Codingstandard, die so nahezu "aus Prinzip" gebrochen werden. Dass die zu Grunde liegende Sprache C (laut Angaben von Kollegen soll's ANSI C 99 werden*) und dass der Quälkot das Markenzeichen Historisch Gewachsen™ verdient**, brauch ich glaube nur am Rande erwähnen.

Aber was mich jetzt eher interessiert, als wie es besser geht (obwohl ich auch hier gern Vorschläge annehme), ist die Frage, wie man nachhaltig dafür sorgen kann, dass die vorhandenen Regeln für Quelltext mit Stil™ besser eingehalten*** werden, bzw. wie man anderen die Wichtigkeit von Konzepten wie "Bad Code That Looks Bad" näher bringen kann.

Bin auf eure Anregungen gespannt.

P.S.: Mit Kollegen reden bin ich schon immer bei, als Praktikant sehen da die Chancen nur immer recht mager aus. Selbst wenn man bereits zahlreiche Bugs aus dem bestehenden Source gefischt hat ...

*Ähnlichkeiten nur entfernt erkennbar
**Die Traditionsmarke Historisch Gewachsen™ steht für erhabenste Qualität aus dem Hause IOCCC.
***Quelltext mit Stil™ ist eine Qualitätskennung für Quelltext, der sauber, strukturiert, effizient und funktional ist und durch Einfachheit und Übersichtlichkeit glänzt.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Viel Spass, Don Quijote ...

Gegen Historisch gewachsen und menschliche Bequemlichkeit is kein Kraut gewachsen, schon gar nicht das der Vernunft ... (meine Erfahrung)

Moin!

Sowas klappt nur, wenn du Unterstützung von "ganz Oben" hast (QM-Beauftragter, der nur der Geschäftsleitung untersteht oder ebendiese Selbst). Hast du das nicht - vergiss es...

cu
Narses

Das einzige was vielleicht noch helfen kann, wäre ne kleine Demo, also häßlichen Code hernehmen, Fehlerbeschreibung dazu und sagen, wo ist der Fehler. Danach dann den Konter mit hübschem Code und gleiches Vorgehen. Vielleicht geht dem einen oder anderem ja ein Lichtlein auf, aber vermutlich wirst du dann auch mit Existenzängsten konfrontiert (wenn das jeder versteht, ist man ersetzlich) und dann gehts wieder auf die Windmühlen. Gibt ja keine Arbeitssicherheit für Quellcode...ansonsten sind keine Zeit und kein Geld immer 2 Jahre extra

BenBE hat folgendes geschrieben :

Aber was mich jetzt eher interessiert, als wie es besser geht (obwohl ich auch hier gern Vorschläge annehme), ist die Frage, wie man nachhaltig dafür sorgen kann, dass die vorhandenen Regeln für Quelltext mit Stil™ besser eingehalten*** werden, bzw. wie man anderen die Wichtigkeit von Konzepten wie "Bad Code That Looks Bad" näher bringen kann.

Grundsätzlich wird wohl jeder nicken, und sagen, ja du hast ja recht und es dann doch wie gewohnt 'unsauber' machen. Neben den Ängsten (siehe Ene's Post) wird auch fast jeder insgeheim seinen Stil für das einzig wahre halten, da das 'anders denken' (was vorraussetzung für sauberen Code schreiben ist) kaum jemanden liegt/gefällt.

Ich denke, das einzige, was wirkt, ist Druck (z.b. Einpflegeverbot (wenn mit CVS o.ä.), Abmahnung, etc.) alles andere wird über kurz oder lang wieder einschlafen und damit scheitern.
My 2 Cents

Stilblüten wie, dass einmal funktionierender Code nicht mehr anzufassen ist (außer, er muss erweitert werden), erwähn ich jetzt mal nicht Und Optimierung durch den Compiler ist -O2 wenn's hoch kommt (meist eher -O0).

Und die erwähnte Copy Pasta mit Compiler-Defines en mas ist grausam. Mit Hilfe einer Inline-Funktion könnte man 8000 Zeilen auf ~800 reduzieren, bei ähnlicher Code-Geschwindigkeit ... Mit einer Schleife und etwas Compiler Switches im Header-File sogar die Code-Größe gegenüber jetzt reduzieren ... Mein Bericht zur Einarbeitung, den ich geschrieben hab, umfasste 5 Seiten nur mit Verbesserungsvorschlägen (2 Seiten davon Bugs + Verbesserung)...

Ich hab jetzt mal den "offiziellen" Weg "Persistenz" genommen, und reich einfach ähnlich wie Shareware immer mal wieder nen Nag Screen weiter

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Pass auf, das du einige Mitstreiter hast und nicht evtl. als 'der, der es immer besser weiss' irgendwann ins abseits gestellt wirst (will sagen, vergiss bei aller logischen richtigkeit nie die soziale Komponente solcher 'Belehrungen').
Gibt auch leute, die sich gegen sowas entgegen aller Logik auch auf andere Art und weise wehren, um sich ja nicht ändern zu müssen.
(just an old man's experience ...)

In den aktuellen Team Foundation Server-Versionen gibt es genau zu diesen Themen Funktionen, die z.B. dafür sorgen, dass Code eine bestimmte Metrik erfüllen muss oder sogar, dass für jede öffentliche Methode eine Testmethode implementiert und erfüllt werden muss. AFAIK kann man genau hier auch dafür sorgen, dass bestimmte Richtlinien bzgl. Programmierung erfüllt sein müssen, bevor man überhaupt etwas einchecken kann.

Das wäre dann sozusagen die Holzhammermethode, aber meine Erfahrung ist: Es funktioniert nicht anders. Denn ansonsten kommt wieder einer und denkt sich: "Das will ich jetzt noch schnell fertig und funktionsfähig bekommen" und schludert den Code mehr oder weniger hin.

Ich denke, die ganzen ALM-Tools werden in dieser Hinsicht auch ähnliche Funktionen bieten, die dann auch für C/C++ funktionieren.

Am besten suchst du dir eine Studie, vielleicht von IBM oder Microsoft, die zeigt, dass man mit sauberem Code Geld sparen kann (weniger Bugs, bessere Maintainability, etc.). Damit gehst du zu jemandem mit Budgetverantwortung und hoffst auf ein Wunder.

Das wird wohl nicht geschehen, aber im Idealfall gäbe es daraus eine verbindliche Richtlinie und Code-Reviews, um die Code-Qualität zu prüfen. Für Code-Reviews gibt es zu mindest solche Studien, die zeigen, dass man damit Geld spart.

BenBE hat folgendes geschrieben :

Mein Bericht zur Einarbeitung, den ich geschrieben hab, umfasste 5 Seiten nur mit Verbesserungsvorschlägen (2 Seiten davon Bugs + Verbesserung)... Ich hab jetzt mal den "offiziellen" Weg "Persistenz" genommen, und reich einfach ähnlich wie Shareware immer mal wieder nen Nag Screen weiter ;-)

Hm, was willst Du eigentlich erreichen? Wenn ich dich richtig verstanden habe, machst Du dort ein Praktikum und bist nicht der neue Chef der Entwicklungsabteilung. Das Ziel eines Praktikums ist, dass man lernt, wie die Praxis aussieht, und das hast Du jetzt gesehen. Wenn Du so weiter machst, wie oben beschrieben, wirst Du noch eine Erfahrung machen: Niemand mag einen Besserwisser und Mobbing kann ziemlich fies sein.

Du hast vermutlich vollkommen recht damit, dass die gaengige Praxis katastrophal ist, aber als Praktikant wirst Du daran nichts aendern. Hak es ab als Erfahrung, insbesondere die, dass Du dort nicht arbeiten willst.

twm

Ich denke, als Praktikant sollte man den Ball erst noch mal flach halten. Zumal es ein Kampf gegen Windmühlen sein würde.
Du musst Dich gegen etablierte Leute durchsetzen, die "das schon immer so machen.". Das ist sehr schwer.

Ich habe in einer Firma gearbeitet, wo der Leiter der Entwicklungsabteilung eine Pfeife war, sich aber in Richtung Geschäftsleitung als Könner verkaufen konnte. Der Code war immer unter aller Sau.

Es gab einen Programmierstandard, an den sich niemand gehalten hat. Das lag daran, dass niemand den Sinn und Zweck verstanden hat. Außerdem wurde der Standard 10 Jahre nicht aktualisiert.
Und dazu kam noch die Firmenpolitik, den Entwicklern auf 15 Minuten genau vorzugeben, wie viel Zeit man für eine Aufgabe hat. Da wurde dann irgendwie auf die Schnelle was zusammengeschustert und abgegeben. Hauptsache, die Sache funktioniert auf den ersten Blick und man kann im Planungstool die Aufgabe als "fertig" markieren. Dabei wurde nie beachtet, ob die Änderungen an anderer Stelle der Software Auswirkungen haben. Die Projektleiter haben das dann ungetestet 2 Wochen später beim Kunden vor Ort installiert. 2 Tage später merkt der Kunde, dass die Programmierung *mist*e ist, weil voll mit Bugs, er beschwert sich beim Projektleiter. Bis das wieder beim eigentlichlichen Entwickler aufschlägt, sind locker 3 Wochen vergangen.

Abgesehen von der Programmqualität hat diese Firmenpolitik auch das Klima in der Firma komplett versaut. Das war einer der Gründe, weshalb ich dort gekündigt habe.

dummzeuch hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Mein Bericht zur Einarbeitung, den ich geschrieben hab, umfasste 5 Seiten nur mit Verbesserungsvorschlägen (2 Seiten davon Bugs + Verbesserung)... Ich hab jetzt mal den "offiziellen" Weg "Persistenz" genommen, und reich einfach ähnlich wie Shareware immer mal wieder nen Nag Screen weiter Hm, was willst Du eigentlich erreichen?

Ziel von mir ist weniger, alles bestehende über den Haufen zu werfen, sondern die verhärteten Krusten soweit aufzubrechen, dass zumindest ein Überdenken angedacht wird. Wenn ich Glück hab, dürfte ich beim neuen Coding-Standard eine Chance der Mitbestimmung bekommen ... Muss sich aber noch zeigen.

dummzeuch hat folgendes geschrieben :

Wenn ich dich richtig verstanden habe, machst Du dort ein Praktikum und bist nicht der neue Chef der Entwicklungsabteilung.

Korrekt erkannt. Und genau deshalb ist es auch nicht mein Ziel, alles auf Biegen und Brechen durchzusetzen; alleinig das Überdenken anzuregen.

dummzeuch hat folgendes geschrieben :

Das Ziel eines Praktikums ist, dass man lernt, wie die Praxis aussieht, und das hast Du jetzt gesehen.

War mir vorher schon bekannt Hab eigentlich nichts anderes erwartet

dummzeuch hat folgendes geschrieben :

Wenn Du so weiter machst, wie oben beschrieben, wirst Du noch eine Erfahrung machen: Niemand mag einen Besserwisser und Mobbing kann ziemlich fies sein.

Es ist ja nicht so, dass ich nicht auch zu kompromissen bereit wäre. Wenn ich etwas vorschlage begründe ich schon (und das nicht nur mit "gefällt mir halt".

Und gegen Mobbing gibt es durchaus auch Möglichkeiten, sich zu wehren, auch wenn das nicht grad dem Arbeitsklima zuträglich ist. Das ist aber nicht Thema dieser Diskussion

dummzeuch hat folgendes geschrieben :

Du hast vermutlich vollkommen recht damit, dass die gaengige Praxis katastrophal ist, aber als Praktikant wirst Du daran nichts aendern.

Zitat:

Wo kämen wir hin, wenn jeder sagte, wo kämen wir hin, und keiner ginge um zu schauen, wo wir hinkämen, wenn wir gingen.

Das etwas Praxis ist, heißt nicht, dass man es nicht ändern darf!

dummzeuch hat folgendes geschrieben :

Hak es ab als Erfahrung, insbesondere die, dass Du dort nicht arbeiten willst.

Schon geschehen, aber aus anderem Grund.

Nersgatt hat folgendes geschrieben :

Ich denke, als Praktikant sollte man den Ball erst noch mal flach halten. Zumal es ein Kampf gegen Windmühlen sein würde. Du musst Dich gegen etablierte Leute durchsetzen, die "das schon immer so machen.". Das ist sehr schwer.

Hier hilft ein wenig Narrenfreiheit, die ich auf Grund meiner Aufgabe habe Mehr kann ich dazu aber nicht sagen ...

Nersgatt hat folgendes geschrieben :

Ich habe in einer Firma gearbeitet, wo der Leiter der Entwicklungsabteilung eine Pfeife war, sich aber in Richtung Geschäftsleitung als Könner verkaufen konnte. Der Code war immer unter aller Sau.

Kein Wunder bei dem antiken Stand, den die IT-Branche noch immer nach >50 Jahren hat. Problem sind oftmals Quereinsteiger und die vorherrschende Praxis des "Es funktioniert, warum richtig machen?", die man sogar hier im Forum bei vielen Anfängern oft beobachten kann. Es muss keiner hocheffizienten, 100% maschinenlesbar dokumentierten Code nach Standards von Übermorgen schreiben, aber doch zumindest soweit einen Grundstand an aktuell gebräuchlichen Techniken zur Wartbarmachung und Pflege von Code sollte jeder kennen und umsetzen.

Nersgatt hat folgendes geschrieben :

Es gab einen Programmierstandard, an den sich niemand gehalten hat. Das lag daran, dass niemand den Sinn und Zweck verstanden hat. Außerdem wurde der Standard 10 Jahre nicht aktualisiert.

Es gibt immer mal aktuellere Fassungen, und aktuell wird auch wieder an einer gearbeitet. Von daher bietet es sich geradezu an JETZT aktiv zu werden, um mehr aus dieser Chance zu machen.

Nersgatt hat folgendes geschrieben :

Und dazu kam noch die Firmenpolitik, den Entwicklern auf 15 Minuten genau vorzugeben, wie viel Zeit man für eine Aufgabe hat. Da wurde dann irgendwie auf die Schnelle was zusammengeschustert und abgegeben. Hauptsache, die Sache funktioniert auf den ersten Blick und man kann im Planungstool die Aufgabe als "fertig" markieren. Dabei wurde nie beachtet, ob die Änderungen an anderer Stelle der Software Auswirkungen haben. Die Projektleiter haben das dann ungetestet 2 Wochen später beim Kunden vor Ort installiert. 2 Tage später merkt der Kunde, dass die Programmierung *mist*e ist, weil voll mit Bugs, er beschwert sich beim Projektleiter. Bis das wieder beim eigentlichlichen Entwickler aufschlägt, sind locker 3 Wochen vergangen.

Die Zeiten, in denen Entwickler für ihre Fehler haften sind vorbei. Kaum einer identifiziert sich mehr mit seinem Code, so dass er wie Daniel J. Bernstein mal eben 1000 US-Dollar für das Finden eines Bugs ausschreibt. Ehrlich: Wer von euch ist von seinen Programmen so überzeugt, dass er dies tun würde? Hände hoch!

Also ich seh jetzt keinen Freiwilligen ...

Ich hab heut 5 Minuten gebraucht, um dem einen Kollegen zu erklären, warum ein Code Standard nicht dafür da ist, Code zu formatieren, sondern dazu da sein sollte, schlechten Code als solchen herauszustellen: Eben damit er vermieden wird. Guter Code ist mit unter auch Kunst. Genauso wie IOCCC sehr inspirierend sein kann - gerade, wie man es besser (nicht) macht

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben :

Die Zeiten, in denen Entwickler für ihre Fehler haften sind vorbei. Kaum einer identifiziert sich mehr mit seinem Code, so dass er wie Daniel J. Bernstein mal eben 1000 US-Dollar für das Finden eines Bugs ausschreibt. Ehrlich: Wer von euch ist von seinen Programmen so überzeugt, dass er dies tun würde? Hände hoch!

Wenn die Bezahlung zu der Vertragsstrafe (1000 Dollar für einen Bug) passst, warum nicht? Es ist immer die Frage, ob der Auftraggeber/Arbeitgeber den Aufwand für sehr aufwändige Tests bereit zu zahlen ist. Da kommt es auch auf die Anwendung an. Für eine Steuerung einer Herz-Lungen-Maschine halte 1000 Dollar für einen Bug durchaus angemessen. Für den tausendsten MP3-Player eher nicht.

Wenn man das wirklich angehen möchte, sollte man sich vorher ein paar grundlegende Dinge zu Gesicht führen und wirklich mit Kommunikationsmitteln arbeiten, ggf vorher üben! Der wichtigste Grundstein ist meist, dass man sich selber sagt, dass das alles echt nette Menschen sind, mit denen man wirklich gerne zusammenarbeitet. Tips sind für mich folgende Sachen:

1) Immer freundlich und sachlich bleiben.
2) Einfache und eindrucksvolle Beispiele erhöhen den Aha-Effekt und regen wohl am Ehesten zum Mitarbeiten an.
3) Versuche viel mit Fragen zu arbeiten, sobald du merkst, dass die Leute mitarbeiten -> Eigeninitiative fördern
3a) Niemals den Schwung dabei herausnehmen, sondern nur steuernd wirken (wenn sich Leute verzetteln, kurz zusammenfassen und fragen ob es so richtig ist, ob jemand etwas hinzufügen möchte und möglichst schnell auf weitere Punkte eingehen, damit es "am Rollen" bleibt)
4) Wenn jemand ganz und gar dagegen ist, entweder rausschmeißen oder im Recht geben und gleich fragen, wie er es denn verbessern würde.
4a) Die Leute müssen beschäftigt werden, niemals ihm widersprechen, seine eigenen Bedürfnisse zurückstellen.
5) Von vornherein klarstellen, dass man nicht alles auf einmal ändern will.
6) Von vornherein klarstellen, dass man bei Änderung mit längeren Zeiten (geringerer Produktivität) rechnen muss
7) Von vornherein klarstellen, dass erst bei Erfolg eine Steigerung der Produktivität anfängt (hier helfen Bilder sehr gut)
Leute auch gern direkt ansprechen (sehen sie das auch so...etc), damit kann man sie aktiv halten und wenn hinterher gemeckert wird (ich habe sie gefragt und habe ihre verhalten als zustimmung empfunden, bitte helfen sie mir das zu verbessern und unterbreiten sie mir ihre vorschläge o.ä.)

Es geht sehr viel darum viele "Profis" unter einen Hut zu bekommen und das ist sehr viel vom Klima abhängig. Man sollte aber generell versuchen alles aufzunehmen und wenn möglich direkt umzusetzen (Lob und Kritik). Dafür braucht man ein bisschen mehr als Übung

Für jemanden der mehr in der Projektleitung oder mit NLP zu tun, wird das nichts neues sein, da es als "allgemeine Regeln" wohl anzusehen sind. Aber man muss da wirklich hart an sich selber arbeiten um es vernünftig umzusetzen, sonst wird man zu schnell durchschaut