Komplexität: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
Zeile 2: | Zeile 2: | ||
|baustelle=Ja | |baustelle=Ja | ||
|blatt=1 | |blatt=1 | ||
|beschreibung= | |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''' | '''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''' | '''Große''' Fälle unnötiger Komplexität treten methoden- oder klassenübergreifend auf. | ||
Beide Kategorien werden als eigene Richtlinie behandelt und geben demnach | 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:
Assertions, Duplikate, Gottklasse, Hartcodieren, IO/UI, Reimplementierung, Ungeeigneter Schleifentyp