Diese Woche sind wir über einen kleinen Bug gestolpert, der normalerweise wahrscheinlich behoben und schnell wieder vergessen worden wäre.
Die Annahme war, dass ein Optional.of ein leeres Optional liefert, wenn das übergebene Objekt null ist. Tatsächlich wäre das dann aber mit Optional.ofNullable(…) zu lösen, da unser Beispiel eine NullpointerException werfen würde (So auch in der JavaDoc beschrieben).
Der erfahrene #java Entwickler lächelt hier vermutlich nur müde, denn das weiß man doch.
Für mich ist das aber ein gutes Beispiel dafür, wie wichtig es ist, Code so zu schreiben, dass andere Entwickler ihn wirklich verstehen, ohne lange darüber nachdenken zu müssen.
Nehmen wir als weiteres Beispiel folgendes Codeschnipsel:
var firstPosition = message.getPositions().stream().findFirst();
final Date datLeist = firstPosition.map(p -> p.getEdif510p().getEDLSDAT())
.orElse(message.getEdif100p().getEDREDA());Fachlich geht es darum, das Leistungsdatum der Rechnung zu ermitteln. Gibt es Artikelpositionen, soll das Leistungsdatum der ersten Position verwendet werden, ansonsten ist das Rechnungsdatum zu verwenden.
Wir haben in diesem konkreten Fall diskutiert, ob Bezeichnungen wie EDLSDAT oder EDREDA, welche noch aus den Zeiten kamen, als Variablen keine längeren Namen haben durften, auch heute noch so weiterverwendet werden sollten.
Im Endeffekt haben wir nun folgenden durch eigene Tests abgesicherte Methode geschrieben:
public static Date getLeistungsDatum(InhouseMessage message) {
Date rechnungsDatum = message.getEdif100p().getEDREDA();
var erstePosition = message.getPositions().stream().findFirst();
return erstePosition.map(p -> {
Date leistungsDatumDerPosition = p.getEdif510p().getEDLSDAT();
return leistungsDatumDerPosition;
}).orElse(rechnungsDatum);
}Für mich sehr spannend war es, zu sehen, wie aus eigentlich zwei bis drei unscheinbaren Zeilen Code eine eigene Methode mit eigenen Tests wurde.