Skip to content

en Translation coming soon

Maintainability

Eine Methode sollte nicht mehr als 7 Statements haben (GCG15001) recommendation level 1

Eine Methode mit mehr als sieben Statements macht zu viel oder verstößt gegen das Single Responsibility Principle. Außerdem wird es mit jedem Statement aufwändiger zu verstehen, was der Code machen soll. Eine Methode mit mehr Statements sollte entsprechend in mehrere kleine Methoden, die einen selbsterklärenden Namen haben, runtergebrochen werden. Der High-Level Algorithmus muss allerdings weiterhin verständlich sein.

Eine Ausnahme hierbei können Tests, Builder oder Methoden, die den Anwendungsfluss steuern sein. Es sollte dennoch geprüft werden, ob die Anzahl der Statements pro Methode durch Pattern oder verschachtelte Prüfungen reduziert werden können, wodurch die Verständlichkeit und Wartbarkeit gesteigert werden kann.

So geschlossen wie möglich, so offen wie nötig (GCG15002) recommendation level 1

Alle Typen und Member sollten standardmäßig nur von denen gesehen und genutzt werden können, die auf diese Typen und Member direkt zugreifen müssen. Entsprechend sollten Member standardmäßig private und Typen internal sein.

Außerdem sollten standardmäßig weder Member noch Typen überschrieben oder beerbt werden können.

Nur für den Fall, dass von Außen auf einen Typen oder dessen Member zugegriffen werden muss, sollte die Sichtbarkeit langsam erhöht werden.

Vermeidung von Ausdrücken mit doppelter Negierung (GCG15003) recommendation level 2

In manchen Fällen ist es sinnvoll, oder gegeben, dass eine Variable bzw. ein Typen-Member den Negativfall abdeckt, allerdings sollte es vermieden werden, diese in einer negierten Bedingung zu verwenden.

bool hasOrders = !customer.HasNoOrders;

Doppelte Verneinungen sind schwerer zu verstehen und werden oft überlesen.

Ein Typ, eine Datei (GCG15004) recommendation level 2

Eine Source-Datei sollte genau einen Typen enthalten, bzw. einen Zweck dienen.

Die Datei sollte auch nach diesem Typen benannt sein.

Ausnahme: Nested-Types sollten Teil der Datei des übergeordneten Typen sein.

Ausnahme: Typen, die sich nur durch die Anzahl an generischen Typ-Parametern unterscheiden, sollten Teil der gleichen Datei sein.

Don't use magic numbers (GCG15005) recommendation level 1

Vermeide die Verwendung von Literal Values, sowohl Zahlen als auch Strings. Stattdessen sollten Konstanten verwendet werden.

Ausgenommen sind Strings für das Logging, sowie Werte, die durch ihren Context eindeutig sind und zukünftig nicht geändert werden.

mean = (a + b) / 2; // okay
WaitMilliseconds(waitTimeInSeconds * 1000); // clear enough

Anmerkung: Enum-Typen eigenen sich oft für Konstanten genutzt werden.

Explizit, statt Implizit (GCG15006) recommendation level 1

Die Deklarierung sollte immer so explizit wie möglich sein.

Variablen sollten so spät wie möglich deklariert und initialisiert werden (GCG15007) recommendation level 2

Variablen sollten zu dem Zeitpunkt deklariert und initialisiert werden, an dem sie gebraucht werden.

Deklariere und Weise immer nur eine Variable pro Zeile zu (GCG15008) recommendation level 2

Vermeide Ausdrücke wie

var result = otherVariable = GetSomeValue();

Keine explizite Vergleiche auf True und False (GCG15009) recommendation level 1

if (condition == false) // wrong; bad style  
if (condition != true) // also wrong  
if (((condition == true) == true) == true) // where do you stop?  
if (condition) // OK

Verändere nicht die Loop-Variable innerhalb eines for-Loops (GCG15010) recommendation level 2

Das Updaten der Loop-Variablen innerhalb des Loops für in aller Regel zu Verwirrung, besonders, wenn sie an mehr als einer Stelle verändert wird.

for (int index = 0; index < 10; index++)  
{  
    if (someCondition)
    {
        index = 11; // Wrong! Use 'break' or 'continue' instead.  
    }
}

Vermeide verschachtelte Loops (GCG15011) recommendation level 2

Methoden mit verschachtelten Loops ist schwerer zu verstehen, als eine Methode mit nur einem Loop. Werden verschachtelte Loops benötigt, sollten diese durch andere Mittel ersetzt werden, oder in mehrere Methoden aufgeteilt werden.

Füge immer den default-Block nach dem letzten case in einem switch-Statement hinzu (GCG15012) recommendation level 1

Wenn der default-Block leer gelassen werden soll, dann füge ein aussagekräftiges Kommentar hinzu. Wenn der Block nicht erreicht werden darf, dann wird eine Exception, um zukünftige Änderungen zu erkennen, die bisher nicht erwartet werden.

Beende jedes if-else-if-Statement mit einem else-Statement (GCG15013) recommendation level 2

Verwende den letzten else-Block für das Standardverhalten. Wenn dieser Block nicht erreicht werden kann oder darf, dann wird eine Exception.

Verwende ein einfaches Conditional Assignment Statement, statt einem if-else-Konstrukt (GCG15013) recommendation level 2

// rather than:
bool isPositive;

if (value > 0)
{
    isPositive = true;
}
else
{
    isPositive = false;
}

// write:
bool isPositive = (value > 0);

Verwende switch-Statements, statt if-else-Statement (GCG15014) recommendation level 3

In vielen Fällen kann ein switch-Statement ein if-else-Statement ablösen und es dadurch verständlicher und wartbarer gestalten.

Vermeide Signaturen mit mehr als 3 Parametern (GCG15015) recommendation level 1

Um Konstruktoren, Methoden, Funktionen etc. klein und fokussiert zu halten, muss die Anzahl der Parameter gering gehalten werden. Es empfiehlt sich, die Anzahl auf drei Parameter zu beschränken.

Konstruktoren, zum Erstellen von Typen, die mehrere Parameter erwarten, können z. B. durch das Builder-Pattern vereinfacht werden.

Generell gilt, desto weniger Parameter, umso einfacher und verständlicher ist die Methode. Außerdem resultiert das Testen von Methoden, die viele Parameter erwarten, in vielen Szenarien, die abgedeckt werden müssen.

Vermeide Signaturen, die einen bool-Parameter haben (GCG15016) recommendation level 2

Folgendes Beispiel:

public Customer CreateCustomer(bool hasPlatinumLevel) {}

Auf den ersten Blick wirkt die Signatur verständlich, aber sobald die Methode verwendet wird, geht die Verständlichkeit verloren:

Customer customer = CreateCustomer(true);

Oft macht eine Methode, die einen Boolean erwartet mehr als eine Sache. Eine Alternative ist es, den Boolean mit einer Enumeration zu ersetzen.

Kommentiere niemals Code aus (GCG15017) recommendation level 1

Veröffentliche niemals eine Änderung, in der Code auskommentiert ist. Niemand wird wissen, weshalb der Code auskommentiert ist. Wurde es temporär zum Testen entfernt? Ist es ein kopiertes Beispiel? Kann der Code gelöscht werden?

Schreib code, der leicht zu debuggen ist (GCG15018) recommendation level 1

Vermeide es, zu viele Statements innerhalb einer einzigen Zeile zu schreiben. Dadurch können Debugger effektiver genutzt werden.

Überladungen sollten sich gegenseitig aufrufen (GCG15019) recommendation level 2

Diese Regel betrifft nur Überladungen, die optionale Parameter bereitstellen.

public string ToString()
{
    return ToString(Format.Default);
}

public string ToString(Format format)
{
    return ToString(format, Culture.Default);
}

public string ToString(Format format, Culture culture)
{
    // return result
}

Lagere komplexe Ausdrücke in separaten Methoden aus (GCG15020) recommendation level 1

Komplexe Ausdrücke, z. B. Bedingungen, sollten in Methoden mit eindeutigen Namen ausgelagert werden, damit diese verständlicher werden.

Last update: 2021-09-26
Back to top