Typische Fehler im Java-Code.

Dieses Material enthält die typischsten Fehler, die ich im Java-Code der Leute gesehen habe, die mit mir arbeiten. Die statische Analyse (wir verwenden qulice ) kann aus offensichtlichen Gründen nicht alle derartigen Fehler erkennen, weshalb ich beschlossen habe, sie hier aufzulisten. Alle diese Fehler hängen mit der objektorientierten Programmierung im Allgemeinen und Java im Besonderen zusammen.

Klassennamen

Ihre Klasse sollte eine Abstraktion eines realen Objekts ohne „ Validatoren “ , „ Controller “ , „ Manager “ usw. sein . Wenn Ihr Klassenname mit „-er“ endet, ist das Design schlecht. Und natürlich sind Anti-Pattern-Hilfsklassen wie StringUtils , FileUtils und IOUtils von Apache großartige Beispiele für schreckliche Entwurfsmuster. Fügen Sie niemals Suffixe oder Präfixe hinzu, um zwischen Schnittstellen und Klassen zu unterscheiden. Alle diese Namen sind zum Beispiel schrecklich: IRecord , IfaceEmployee oder RecordInterface . Normalerweise ist der Schnittstellenname der Name des realen Objekts, während der Klassenname die Implementierungsdetails erläutern sollte. Wenn zur Implementierung nichts Konkretes gesagt werden kann, genügen auch die Bezeichnungen „ Default “, „ Simple “ oder ähnliches. Beispielsweise: class SimpleUser implements User {}; class DefaultRecord implements Record {}; class Suffixed implements Name {}; class Validated implements Content {};

Methodennamen

Methoden können entweder „ etwas “ oder „ void “ zurückgeben. Wenn eine Methode etwas zurückgibt, sollte ihr Name erklären, was zurückgegeben wird. Beispiel (verwenden Sie nicht das Präfix „ get “): boolean isValid(String name); String content(); int ageOf(File file); Wenn „ void “ zurückgegeben wird, sollte der Name verdeutlichen, was die Methode tut. Beispiel: void save(File file); void process(Work work); void append(File file, String line); Es gibt nur eine Ausnahme von dieser Regel – JUnit- Testmethoden . Sie werden im Folgenden beschrieben.

Namen der Testmethoden

Methodennamen in JUnit-Tests müssen als englischer Satz ohne Leerzeichen aufgebaut sein. Dies lässt sich anhand eines Beispiels einfacher erklären: Es ist /** * HttpRequest can return its content in Unicode. * @throws Exception If test fails */ public void returnsItsContentInUnicode() throws Exception { } wichtig, den ersten Satz Ihres JavaDoc mit dem Namen der Klasse, die Sie testen, gefolgt von „ can “ zu beginnen. Der erste Satz sollte also immer so lauten: „ Jemand kann etwas tun .“ Der Methodenname wird dasselbe aussagen, jedoch ohne den Testgegenstand. Wenn ich es am Anfang des Methodennamens hinzufüge, erhalte ich einen vollständigen englischen Satz, wie im obigen Beispiel: „ HttpRequest gibt seinen Inhalt in Unicode zurück .“ Bitte beachten Sie, dass der Name der Testmethode nicht mit „ can “ beginnt. Nur JavaDoc-Kommentare beginnen mit „ can “. Darüber hinaus sollten Methodennamen nicht mit einem Verb beginnen ( Aus dem Übersetzer: Offenbar meint der Autor die Imperativform des Verbs ). Es empfiehlt sich, beim Deklarieren einer Testmethode anzugeben, dass eine Ausnahme ausgelöst wird.

Variablennamen

Vermeiden Sie zusammengesetzte Variablennamen wie timeOfDay , firstItem oder httpRequest . Ich meine sowohl Klassenvariablen als auch Methodenvariablen. Der Variablenname sollte lang genug sein, um Mehrdeutigkeiten im Gültigkeitsbereich zu vermeiden, aber nach Möglichkeit nicht zu lang. Der Name muss ein Substantiv im Singular oder Plural sein. Beispiel: Manchmal kann es zu Kollisionen zwischen Konstruktorparametern und Klassenfeldern kommen, wenn der Konstruktor Eingabedaten im erstellten Objekt speichert. In diesem Fall empfehle ich die Bildung einer Abkürzung durch Entfernen der Vokale. Beispiel: In den meisten Fällen ist der beste Variablenname der Name der entsprechenden Klasse. Schreiben Sie es einfach groß und schon ist alles in Ordnung: Machen Sie jedoch niemals dasselbe für primitive Typen wie oder . Sie können Adjektive auch verwenden, wenn es mehrere Variablen mit unterschiedlichen Eigenschaften gibt. Zum Beispiel: List names; void sendThroughProxy(File file, Protocol proto); private File content; public HttpRequest request; public class Message { private String recipient; public Message(String rcpt) { this.recipient = rcpt; } } File file; User user; Branch branch; Integer number String string String contact(String left, String right);

Konstrukteure

Es sollte ausnahmslos nur einen Konstruktor geben, der Daten in Objektvariablen speichert. Alle anderen Konstruktoren müssen diesen mit anderen Parametern aufrufen: public class Server { private String address; public Server(String uri) { this.address = uri; } public Server(URI uri) { this(uri.toString()); } }

Einmalige Variablen

Vermeiden Sie unbedingt einmalige Variablen. Mit „Einweg“ meine ich Variablen, die einmal verwendet werden. Wie in diesem Beispiel: String name = "data.txt"; return new File(name); Eine Variable wird nur einmal verwendet, und der Code kann wie folgt vereinfacht werden: return new File("data.txt"); Manchmal, in sehr seltenen Fällen – meist aufgrund einer besseren Formatierung – können Einmalvariablen verwendet werden. Versuchen Sie jedoch, solche Situationen zu vermeiden.

Ausnahmen.

Ausnahmen sollten natürlich niemals „verschluckt“ werden; sie sollten so hoch wie möglich geworfen werden. Ausnahmen von privaten Methoden müssen extern behandelt werden. Verwenden Sie niemals Ausnahmen, um den Fluss zu steuern. Der Code im Beispiel ist falsch: int size; try { size = this.fileSize(); } catch (IOException ex) { size = 0; } Im Ernst, was ist, wenn die IOException sagt „Datenträger ist voll“, gehen Sie dann davon aus, dass die Dateigröße Null ist, und fahren Sie fort?

Vertiefung.

Beim Einrücken gilt als allgemeine Regel, dass die Klammer entweder die Zeile beenden oder in derselben Zeile schließen muss (für die schließende Klammer gilt die umgekehrte Regel). Im folgenden Beispiel ist der Code falsch, da die erste Klammer nicht in derselben Zeile geschlossen wird und sich dahinter Zeichen befinden. Bei der zweiten Klammer tritt das gleiche Problem auf, da davor Zeichen stehen und in der aktuellen Zeile keine öffnende Klammer vorhanden ist. final File file = new File(directory, "file.txt"); Das richtige Einrücken sollte so aussehen: StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join( Arrays.asList("a", "b") ) ), "separator" ); Die zweite wichtige Regel beim Einrücken ist, dass Sie möglichst viel in einer Zeile platzieren sollten – innerhalb von 80 Zeichen. Das obige Beispiel ist ungültig, da es komprimiert werden kann: StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join(Arrays.asList("a", "b")) ), "separator" );

Redundante Konstanten.

Klassenkonstanten sollten verwendet werden, wenn Sie den Zugriff auf Informationen zwischen Klassenmethoden teilen möchten und diese Informationen ein Merkmal ( ! ) Ihrer Klasse sind. Verwenden Sie keine Konstanten als Ersatz für Zeichenfolgen oder numerische Literale – eine sehr schlechte Praxis, die zur Codeverschmutzung führt. Konstanten müssen (wie andere OOP-Objekte) in der realen Welt eine Bedeutung haben. Was bedeuten diese Konstanten in der realen Welt? class Document { private static final String D_LETTER = "D"; // bad practice private static final String EXTENSION = ".doc"; // good practice } Ein weiterer häufiger Fehler besteht darin, Konstanten in Komponententests zu verwenden, um die Duplizierung von Zeichenfolgen-/numerischen Literalen in Testmethoden zu vermeiden. TU das nicht! Jede Testmethode muss mit ihrem eigenen Satz von Eingabewerten arbeiten. Verwenden Sie bei jeder neuen Testmethode neue Texte und Nummern. Die Tests sind unabhängig. Warum sollten sie also dieselben Eingabekonstanten verwenden?

Testdatenkopplung.

Hier ist ein Beispiel für das Einbinden einer Testmethode: User user = new User("Jeff"); // maybe some other code here MatcherAssert.assertThat(user.name(), Matchers.equalTo("Jeff")); In der letzten Zeile verketten wir „ Jeff “ mit demselben String-Literal, das in der ersten Zeile angegeben wurde. Wenn jemand einige Monate später den Wert in der dritten Zeile ändern möchte, muss er/sie zusätzliche Zeit damit verbringen, zu suchen, wo sonst noch „ Jeff “ in dieser Methode verwendet wird. Um zu verhindern, dass diese Daten hängen bleiben, sollten Sie eine Variable einführen.