Komplexität: Unterschied zwischen den Versionen

Aus Programmieren-Wiki
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 2: Zeile 2:
|baustelle=Ja
|baustelle=Ja
|blatt=1
|blatt=1
|beschreibung=Codestellen sollten so wenig komplex wie möglich gestaltet werden. Meißt lässt sich aber Code erst später in der Entwicklung vereinfachen, wenn die funktionalität ausgereift ist und demnach keine großen Änderungen an dem Quellcode stattfinden.
|beschreibung=Ein wichtiges Ziel beim Programmieren ist, dass der geschriebenen Quellcode einfach von anderen verstanden werden kann. Deshalb sollte immer der einfachste Weg gewählt werden, um eine vorgegebene Funktionalität zu implementieren. Dies bedeutet nicht, dass der Quellcode aus möglichst wenigen Anweisungen und Zeichen bestehen soll (vgl. Code Golf), sondern dass auf unnötige Konstrukte, innerhalb der Vorgaben des Checkstyle und der weiteren Bewertungskriterien, verzichtet werden soll.
Diese Codestellen sollten spätestens dann vereinfacht werden und die Lesbarkeit zu verbessern. Sind im Quellcode zum Schluss noch solche Codestellen vorhanden, sprechen wir von unnötiger Komplexität.


Möglichkeiten, Code zu vereinfachen, werden häufig erst im Laufe der Entwicklung sichtbar. Beim Überarbeiten und Weiterentwickeln sollte stets ein Augenmerk darauf gelegt werden, ob der bestehende Code unnötige Komplexität enthält und einfacher und verständlicher gestaltet werden kann.


Unter Komplexität (im Abzug dann "unnötige Komplexität") unterscheiden wir unter zwei Kategorien - Klein und Groß.
Bei der Bewertung unnötiger Komplexität unterscheiden wir zwei Schweregrade - klein und groß.


'''Kleine''' unnötige Komplexität bezeichnet eine Codestelle die innerhalb einer Methode (oder die Methode selbst) zu komplex gestaltet wurde. Dazu zählen unter anderem Ausdrücke in if-Statements, die nicht vereinfacht wurden.
'''Kleine''' Fälle unnötiger Komplexität sind Code innerhalb einer Methode oder eine ganze Methode, die zu komplex gestaltet wurde. Dazu zählen unter anderem Boolesche Ausdrücke in <syntaxhighlight lang="Java" inline>if</syntaxhighlight>-Statements, die nicht vereinfacht wurden.


'''Große''' unnötige Komplexität bezeichnet dahingegen eine Codestelle, die mehrere Methoden oder sogar Klassenübergreifend ist, die weniger kompliziert hätte modelliert werden können.
'''Große''' Fälle unnötiger Komplexität treten methoden- oder klassenübergreifend auf.


Beide Kategorien werden als eigene Richtlinie behandelt und geben demnach seperat Abzug.
Beide Kategorien werden als eigene Richtlinie behandelt und geben demnach separat Abzug.
|schweregrad=leicht
|schweregrad=leicht
|negativ=<syntaxhighlight lang="Java">
|negativ=<syntaxhighlight lang="Java">

Version vom 17. Oktober 2024, 11:29 Uhr

🚧 Diese Seite befindet sich in Bearbeitung 🚧
🤓 Diese Seite ist eine Bewertungsrichtlinie, die ab Blatt 1 annotiert und ab Blatt 2 abgezogen wird. 🤓

Beschreibung

Ein wichtiges Ziel beim Programmieren ist, dass der geschriebenen Quellcode einfach von anderen verstanden werden kann. Deshalb sollte immer der einfachste Weg gewählt werden, um eine vorgegebene Funktionalität zu implementieren. Dies bedeutet nicht, dass der Quellcode aus möglichst wenigen Anweisungen und Zeichen bestehen soll (vgl. Code Golf), sondern dass auf unnötige Konstrukte, innerhalb der Vorgaben des Checkstyle und der weiteren Bewertungskriterien, verzichtet werden soll.

Möglichkeiten, Code zu vereinfachen, werden häufig erst im Laufe der Entwicklung sichtbar. Beim Überarbeiten und Weiterentwickeln sollte stets ein Augenmerk darauf gelegt werden, ob der bestehende Code unnötige Komplexität enthält und einfacher und verständlicher gestaltet werden kann.

Bei der Bewertung unnötiger Komplexität unterscheiden wir zwei Schweregrade - klein und groß.

Kleine Fälle unnötiger Komplexität sind Code innerhalb einer Methode oder eine ganze Methode, die zu komplex gestaltet wurde. Dazu zählen unter anderem Boolesche Ausdrücke in if-Statements, die nicht vereinfacht wurden.

Große Fälle unnötiger Komplexität treten methoden- oder klassenübergreifend auf.

Beide Kategorien werden als eigene Richtlinie behandelt und geben demnach separat Abzug.


Negativbeispiel

boolean isValid() {
    if (this.sold == false && !(this.price <= 0)) {
        return true;
    }
    return false;

Der Ausdruck ist hier unnötig komplex und kann vereinfacht werden. this.sold == false entspricht dem Ausdruck !this.sold (! invertiert this.sold, entsprechend ist der Ausdruck nur wahr, wenn this.sold false ist). Entsprechend ist this.price > 0 eine vereinfachte Variante von !(this.price <= 0).

Positivbeispiel

boolean isValid() {
    return !this.sold && this.price > 0;
}

Hier wurde der Ausdruck entsprechend vereinfacht, sodass er leichter zu lesen und verstehen ist.


Wenn du diese Seite interessant fandest, findest du hier noch mehr Seite(n) dazu:
AssertionsDuplikateGottklasseHartcodierenIO/UIReimplementierungUngeeigneter Schleifentyp