Wenn du schon fragst, sowas macht mir Spaß
Zur Klasse Goldpreis:
- Felder einer Klasse sollten immer aussagekräftige Namen haben. Ein Buchstabige Variablen kann man innerhalb einer Methode für Zähler etc. verwenden. Aber Felder einer Klasse, sollte sprechende Namen haben. x,g,p und q sind nicht sprechend.
- Der Javadoc am Konstruktor zeigt das auch deutlich. Der zeigt was man nicht mit Javadoc lösen sollte. Guter Code sollte selbsterklärend sein und Javadoc nur ergänzen bzw. Erklärungen lieferen. Wenn man aber Javadoc schreibt um zu erklären, was der Paramater bedeutet, in dem er ihm einen Namen gibt - das ist nicht sinnvoll.
- Die Felder sollten private sein und nicht (So haben sie package Sichtbarkeit, was normalerweise nicht sinnvoll ist)
- Berechne? Was berechnet die? Vollkommen unkarl. Zum einen sollte die einen sprechenden Namen haben und zum anderen wäre der Code viel klarer, wenn die Felder und Variablen sprechende Namen hätte.
- Persönlich bin ich kein Freund der Art der Klammersetzung, ich hab die öffende Klammer lieber in der gleichen Zeile wie den Code. Aber das ist auch Geschmackssache.
- Warum gibt eine Methode "berechne" was aus?
- Die Leerzeile zwischen Javadoc und Konstruktor stört mich
- Dafür fehlt mir eine Leerzeile zwischen Konstruktor und der Methode berechne
- Die Methode berechne ändert die Felder. Das heißt wenn ich auf einem Objekt die mehrfach aufrufe, ändert sich die Ausgabe. Ist das gewünscht?
- Das Feld e sollte eine lokale Variable sein
Zur Klasse Aufgabe1:
- Der falsch eingerückte Kommentar // Hier können sie den Umsatz eingeben - Mindest richtig einrücken
- Sprechende Variablennamen - anstelle von um "umsatz", anstelle von r1/r2 rabatt1/rabatt2
- Klammersetzung inkonsistent. Bei der Deklaration von main ist die öffende Klammer auf der gleichen Zeile, sonst auf einer anderen. Das sollte man konsistent halten.
- Die Einrückung ist da eh wild in der Methode. Die sollte konsistent sein. Insbesondere ist es so schwer zu sehen, was wozu gehört. Es sind auch zu viele Leerzeilen.
- Mal ist nach dem if ein Leerzeichen, mal direkt eine Klammer - das ist inkosistent.
- Ich finde so eine if/else if Kaskade mit Magicnumbers (130/750) nicht schön, insbesondere schlecht erweiterbar. Sinnvoller wäre es zumindest die Grenzen als Konstanten auszulagern. Oder - wenn man das weiter treiben will, eine Klasse dafür machen, die sowohl die Grenze als auch den Rabatt enthält und den Rabatt auch berechnen kann. Den der Wert 130 und 0.03 gehört fachlich zusammen und bildet fachlich eine Einheit - ist hier aber nicht sichtbar.
Viel kann man Eclipse Bordmitteln erschlagen:
- Shift+Strg+F zum formatieren - oder gleich eine Save Action aktivieren, die das macht.
- Eclipse bietet eine Code-Completion, daher ist es egal, wie lang ein Variablenname ist. (so lange man es nicht übertreibt)
