Programmier- und Entwicklungsrichtlinien

[Gumbo]

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.

 

[tomkruse]

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

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.

 

[swalbking]

Hi,

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

Gruß,
swalbking

 

[Vereth]

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.

	// 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.