Hallo!

Ich bin auf der Suche nach einer Art Richtliniensammlung für effiziente- und strukurierte Programmierung im Team. Bisher habe ich nur diverse Coding Styleguides gefunden. Das ist zwar auch nützlich, aber Vorschriften über die korrekte Benennung von Variablen und Methoden und so weiter reicht eben leider nicht aus, um den Code straff, lesbar und halbwegs einheitlich zu halten.

Gibt es zu diesem Thema eventuell Erfahrungen anderer User? Wie bringt man die Mitarbeiter eines Entwickler-Teams dazu, keine "Wucherungen" und Auswüchse mehr zu programmieren? Codeverdoppelung, Unlesbarkeit, mangelnde wiederverwendbarkeit und so weiter würde ich gerne etwas eindämmen. Die Frage ist nur: wie?

viele Grüsse

Thomas.

Ich schreib hier einfach mal meine bescheidene Meinung rein die ich keineswegs als maßgebend bzw. 100% richtig halte. Das nur vorneweg um irgendwelche Auswüchse in Form von Flames zu verhindern auch wenn die Community hier doch recht handzahm ist

Meiner Meinung nach ist es das wichtigste, dass solche Richtlinien nicht von oben diktiert werden sondern im Dialog entwickelt werden. Sprich wo soll das Projekt hin führen, welche Designaspekte möchten wir einhalten (MVC-Modell etc.). Am wichtigsten wird es erstmal sein sich über einige Punkte klar zu werden die den Stil des Programmierens betreffen sofern nicht schon von der Programmiersprache vorgegeben. So Sachen wie Whitespaces oder Tabs und wenn Whitespaces, 4 oder 8 pro Intention etc.. Welchen Naming-Sheme soll für Methoden und Klassen verwendet werden?Soll dieses für Klassen und Methoden gleich sein? Da wären etwa CamelCase, all-lower und all-caps etc..

Zur Wiederverwertbarkeit kann ich eigentlich nur sagen, dass man möglichst immer Base-Klassen schaffen sollte, die relativ allgemein gehalten sind und Code-Dopplungen nur vermeiden kann indem man den Code der anderen liest und evtl. korrigiert und Dopplungen auslagert um sie eben wieder zu verwenden. Dabei bietet es sich an ein Source Code Controll System wie svn oder git zu verwenden (tolle git-repos gibts auf github.com )

Was die Benennung von Variablen anbelangt sollten sie möglichst aussagekräftig benannt sein. Es kann etwa kein Mensch 3 geschachtelte For-Schleifen mit 4 temporären Variablen schnell nachvollziehen wenn diese a, b, c und d heißen.

Und wie du schon sagtest ist es nützlich sich Guidelines anzusehen. Vielleicht helfen dir ja die von Google's Summer of Code weiter.

Achja: Und wenn man sich nicht einigen kann sollte jemand da sein der auch mal auf den Tisch haut

Hallo!

Danke schon mal für Deine Antwort. So ganz habe ich aber glaube ich nicht rübergebracht was ich wollte

Styleguide haben wir hier schon, also wieviele Spaces und wie man Variablenamen benennen soll und so weiter ist geregelt. Was Einrückungen und solche Dinge betrifft, so ist man heutzutage z.B. in C# unter Visual Studio.Net ohnehin schon vom Editor her gezwungen das zu nehmen was dieser einem vorgibt. Ist aber auch nicht das Schlechteste denn so machen es wenigstens alle Leute im Team auf die gleiche Art

Was ich aber eigentlich brauche sind Regeln die z.B. Spaghetti-Code verhindern, Methoden mit ewig langen Parameterlisten verbieten und so weiter. All das was passiert, wenn lange an einer Applikation gearbeitet wird und immer wieder jemand schnell-schnell was dazuprogrammiert weil irgendein Kunde das eben wünscht. Was da nach Jahren dann herauskommt ist absolut unwartbar und mit jedem zusätzlichen Feature begibt man sich auf verdammt dünnes Eis denn das Debugging wird immer schwieriger und Nebenwirkungen sind kaum auszuschließen und sehr schwer zu finden.

Ich hoffe, ich konnte ein wenig besser rüberbringen wo ich hin will

viele Grüsse

Thomas.

Ich kann ja nicht damit rechnen, dass du eine Verhunzung aus dem Hause Microsoft benutzt (Spaß beiseite, solange es funktioniert kann mans auch benutzen).

Was du meinst hat wie du schon sagtest weniger mit Style zu tun sondern mit Programmierpraktik. Das jemand jetzt ewig lange Parameterlisten bei ner Funktion hat kann man ja durch Arrays lösen. Ansonsten kann ich halt nur sagen, dass der Code von anderen gegengelesen wird und die bei Bedarf sagen, dass das so nicht geht. Ordnung bleibt nur bestehen wenn jemand da ist, der sie erhält. Sonst vermüllt alles nach ner Weile. Ich seh jetzt nicht wirklich einen Weg auf dem man das von dir angesprochene verhindern kann.

Zitat von Raubkopierer

Ich kann ja nicht damit rechnen, dass du eine Verhunzung aus dem Hause Microsoft benutzt (Spaß beiseite, solange es funktioniert kann mans auch benutzen).

Ich hab mir das nicht wirklich ausgesucht
Bei Apps für die Industrie wirst Du allerdings nicht oft PHP finden. Vielleicht noch Java, aber auch das nicht sooo oft.

Was du meinst hat wie du schon sagtest weniger mit Style zu tun sondern mit Programmierpraktik. Das jemand jetzt ewig lange Parameterlisten bei ner Funktion hat kann man ja durch Arrays lösen. Ansonsten kann ich halt nur sagen, dass der Code von anderen gegengelesen wird und die bei Bedarf sagen, dass das so nicht geht. Ordnung bleibt nur bestehen wenn jemand da ist, der sie erhält. Sonst vermüllt alles nach ner Weile. Ich seh jetzt nicht wirklich einen Weg auf dem man das von dir angesprochene verhindern kann.

Es soll halt so werden, daß es eben keiner gegenlesen muss, sondern daß man vorher schon gewisse Richtlinien hat. Gegenlesen und dann ändern bei einer Applikation deren Entwicklung Geld kostet ist nicht wirklich eine kostensparende Vorgehensweise

Arrays statt parameterlisten kommen mir jetzt nicht wie eine übersichtlichere Verbesserung vor, oder wie hast Du das jetzt genau gemeint ..?

viele Grüsse

Thomas.

Was ich meinte war das übergeben eines Arrays als Parameter, dass sehr umfangreiche Angaben enthält. Man könnte auch neue Objekt-Typen nutzen. Im Endeffekt ist das eher eine kosmetische Maßnahme.

Hallo,

kauf dir Clean Code:
Original: http://www.amazon.de/Clean-Code-Hand.../dp/0132350882
Übersetzt: http://www.amazon.de/Deutsche-Ausgab.../dp/3826655486
das Buch enthält viele gute Ratschläge und Tipps zum schreiben von gutem Code.

Ansonsten gibt es im Netz zahlreiche gute Sammlungen von Code-Conventions für Java. Beispielsweise die offiziellen Java Code Conventions von Sun:
http://java.sun.com/docs/codeconv/ oder Writing Robust Java Code The AmbySoft Inc. Coding Standards for Java von Scott W. Ambler:
http://www.ambysoft.com/downloads/ja...gStandards.pdf

Gruß Tom

Hallo!

Vielen Dank! Das ist wohl genau das was ich wollte (habs mir noch nicht angesehen, werde das aber gleich machen).

[edit]
Ok, war doch nicht ganz das was ich wollte. Hat noch jemand was in Richtung besser wartbarem Code jenseits von Namenskonventionen und Kommentar-Tipps?
[/edit]

viele Grüsse

Thomas.

Hallo,

Ok, war doch nicht ganz das was ich wollte. Hat noch jemand was in Richtung besser wartbarem Code jenseits von Namenskonventionen und Kommentar-Tipps?

wie gesagt: schau dir Clean Code an. Dort wird genau darüber geredet (Konventionen sind nur ein ganz kleiner Teil)

Ansonsten:
http://mindprod.com/jgloss/unmain.html
http://stackoverflow.com/questions/1...ntainable-code

Gruß Tom

Hallo,

schau dir mal die Eincheck Bedingungen von Visual Studio Team System an, ich meine man könnte dort auch Richtlinien bezüglich der Code-Qualität festlegen.
Vielleicht hilft das weiter.

MfG Pablo

Zitat von tomkruse

Was ich aber eigentlich brauche sind Regeln die z.B. Spaghetti-Code verhindern, Methoden mit ewig langen Parameterlisten verbieten und so weiter. All das was passiert, wenn lange an einer Applikation gearbeitet wird und immer wieder jemand schnell-schnell was dazuprogrammiert weil irgendein Kunde das eben wünscht. Was da nach Jahren dann herauskommt ist absolut unwartbar und mit jedem zusätzlichen Feature begibt man sich auf verdammt dünnes Eis denn das Debugging wird immer schwieriger und Nebenwirkungen sind kaum auszuschließen und sehr schwer zu finden.

Das klingt eher, dass du dich über Entwicklungsmethoden und Prozessmodelle allgemein informieren solltest, wie also die Entwicklung als Ganzes geplant und organisiert werden kann/sollte.

Zitat von Pablorama

Hallo,

schau dir mal die Eincheck Bedingungen von Visual Studio Team System an, ich meine man könnte dort auch Richtlinien bezüglich der Code-Qualität festlegen.
MfG Pablo

Tja, wenn ich das hätte

Zitat von Gumbo

Das klingt eher, dass du dich über Entwicklungsmethoden und Prozessmodelle allgemein informieren solltest, wie also die Entwicklung als Ganzes geplant und organisiert werden kann/sollte.

Ja, das spielt sicher auch mit rein. Aber vor allem geht es eben um die "Gestaltung" des Codes, so daß er auch nach Jahren noch wartbar ist und das vor allem auch von Personen, die nicht damit aufgewachsen sind.

viele Grüsse

Thomas.

Hi,

je nachdem wie deine Problemstellungen aussehen, könnten auch Entwurfsmuster für dich interessant sein.

Gruß,
swalbking

Ich teile das Ganze mal auf in Planungsphase und Implementierungsphase. Bei mir hat sich folgende Vorgehensweise bewährt:

Planungsphase: Verwende eine top-down-Strategie. Dabei solltest du dir nacheinander folgende Fragen beantworten können.

1. Welches Problem willst du lösen?
2. Welche Vorgehensweise wählst du?
3. Welche Klassen brauchst du dafür? Welche Aufgaben sollen sie übernehmen?
4. Wie müssen sie aufgebaut sein? Welche Eigenschaften/Methoden müssen sie haben?
5. Welche privaten Eigenschaften und Hilfsfunktionen sollten sie haben?

Implementierungsphase: Nun solltest du eine bottom-up-Strategie verfolgen.

• Verwende für Dokumentation, Kommentare sowie Variablen- und Methodennamen die englische Sprache!
• Implementiere zuerst die Hilfsklassen. Teste sie, bis sie kugelsicher sind. Das vereinfacht das Debugging, weil du dann weißt, dass du auf funktionierende Klassen aufbaust, du musst dann beim Tracen nicht in jede Unterfunktion hineinspringen, um den Fehler zu suchen.
• Implementiere die Hilfsmethoden robust. Als erstes sollten sie die Parameter auf Plausibilität prüfen. Wie du im Fehlerfall verfährst (Exception, Returncode etc.), ist deine eigene Entscheidung. Trotzdem sollten sie möglichst fehlertolerant sein; manchmal kann nämlich auch das Übergeben einer null-Referenz sinnvoll sein (z.B. bei Rekursion).
• Eine Methode, die eine andere aufruft, sollte das nur dann tun, wenn es sinnvoll ist. Dadurch werden automatisch nur gültige Parameter übergeben. Übertreibe dabei aber nicht; manchmal strafft es auch den Code, wenn du erst durch den Rückgabewert einer Hilfsfunktion herausfindest, dass eine bestimmte Voraussetzung nicht erfüllt ist, und entsprechend reagierst. Dadurch sparst du dir u.U. längliche if-Konstrukte und du kannst sie dann auch beispielsweise in Schleifenbedingungen einsetzen.
• Überlege dir bei void-Methoden, ob diese nicht besser eine this-Referenz zurückliefern sollten. Dadurch kannst du dann beispielsweise eine Methodenverkettung ermöglichen. Bei settern kann man den übergebenen Parameter wieder zurückgeben, um mit diesem weiterrechnen zu können, ähnlich wie bei dem Zuweisungsoperator in C-ähnlichen Sprachen.
• Klassen sollten nicht nur einen Standard-Konstruktor haben. Implementiere auch zusätzliche Konstruktoren, die es ermöglichen, die wichtigsten Eigenschaften bei der Objekterstellung zu setzen. Der Standard-Konstruktor sollte nur daraus bestehen, dass er eine private init()-Methode aufruft. Die kannst du dann bei anderen Konstruktoren und/oder bei einer destroy-Methode wieder verwenden.
• Schreibe nach Möglichkeit generische Klassen. Das erspart dir oft einen ganzen Klassenbaum.
• Methoden sollten selten vier oder mehr Parameter haben. Ist das doch der Fall, dann ist das oft ein Hinweis darauf, dass du entweder variable Parameterlisten verwenden solltest, oder dir eine Hilfsklasse fehlt.
• Wenn du generische Klassen verwendest, eventuell sogar geschachtelt, können die Deklarationen ziemlich lang werden. Kapsele das, indem du dafür entsprechende Sub-Klassen definierst. Unten ist ein Beispiel für Java. Außerdem vereinfacht das eventuelle Codeanpassungen, wenn du z.B. statt eines HashSet's einen HashTree verwenden möchtest.
• Hilfsklassen und -Methoden sollten so allgemein wie möglich und so speziell wie nötig geschrieben sein. Oft ist es so, dass in der Deklaration eines Parameters nur ein Interface oder eine Oberklasse angegeben werden muss.
• Benutze zum Iterieren über eine Auflistung immer die entsprechende for- bzw. foreach-Schleife. Nicht jede Auflistung (Set, Liste etc.) unterstützt einen Zugriff per Index, aber praktisch alle unterstützen das foreach. Das ermöglicht dir nicht nur die freie Wahl des Aufzählungstyps, sondern du kannst den entsprechenden Parameter auch einfach nur als Collection o.ä. deklarieren (siehe Code). Plane auch deinen Algorithmus dem entsprechend.
• Immer wieder merkt man, dass eine Funktion etwas Ähnliches macht wie eine andere. Das kann darauf hindeuten, dass man eine Methode schreiben kann, die von diesen diesen gemeinsam genutzt wird. Hilfsmethoden verkürzen Hauptmethoden!
• Verwende möglichst oft das Schlüsselwort private für Eigenschaften und/oder Methoden. Dein SDK wird es dir beim Autovervollständigen und dem Klassenbaum danken.

Code java:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

// Beispiele für Codeverbesserungen:       // Hilfsklassen zur Verkürzung von Deklarationen     private class LineType extends LinkedList<Boolean>  {private static final long serialVersionUID = 1L;};     private class LineList extends LinkedList<LineType> {private static final long serialVersionUID = 1L;};     private class HintList extends LinkedList<Integer>  {private static final long serialVersionUID = 1L;};     private class RessList extends LinkedList<String>   {private static final long serialVersionUID = 1L;};       // Generische Klasse     public class Beispiel <ConsumerType,RessourceType>       // Collection-Parameter     public boolean addRessources ( Collection<RessourceType> c)     {         if ( c == null ) return false;         boolean ret = false;         for ( RessourceType r : c )         {             ret = addRessource(r,true) ? true : ret;         }         return ret;     }

Es gibt bestimmt noch viele andere nützliche Tipps, aber das sind die, die mir jetzt so ad hoc eingefallen sind. Ich hoffe, ich habe dich nicht überfordert und dir mit diesen Richtlinien geholfen. Jedenfalls wünsche ich dir viel Erfolg bei deinen Projekten.