Bekanntlich wird Code viel öfter gelesen als geschrieben. Häufig wird er auch von anderen Personen gelesen als von derjenigen, die ihn verfasst hat. Und hast du nicht selbst schon erlebt, dass dein eigener Code nur wenige Monate später völlich unverständlich für dich war…? ;-) Umso wichtiger ist es, dass du dir darüber Gedanken machst, wie du deinen Code so lesbar und verständlich wie möglich gestalten kannst.

Doch was macht lesbaren, verständlichen Code aus? Er ist ausdrucksstark, das heißt er drückt aus was er tut. Und zwar genau das, und nur das.

Allerdings ist das Schreiben von lesbarem Code nicht wirklich leicht. Robert C. Martin (“Uncle Bob”) zieht in seinem Buch über Clean Code¹ den Vergleich zur Malerei: Es ist einfach zu erkennen ob ein Bild gut oder schlecht gemalt ist. Aber selbst ein gutes Bild zu malen, dafür braucht es viel Übung.

Daher möchte dir die folgenden 7 Tipps an die Hand geben, die dir dabei helfen können, lesbaren Code zu schreiben.Mehr

Alle halbe Jahre wieder – erscheint ein neues Java-Release. Am morgigen Dienstag, 17.09.2019, ist es wieder soweit: Java 13 wird veröffentlicht.

Folgende Funktionalitäten wurden im Rahmen der Entwicklung des Releases fertig gestellt, und halten Einzug in Java 13:

Mehr

(Eins vorweg: der hier aus pragmatischen Gründen verwendete Begriff “Entwickler” ist geschlechtsneutral gemeint und soll niemanden ausschließen; vielmehr seien damit alle Personen angesprochen die Software entwickeln, unabhängig von der Geschlechtsbezeichnung (m/w/*), der sie sich zugehörig fühlen.)

Software ist allgegenwärtig und spielt in vielen Lebensbereichen eine Rolle. So schlägt sie z.B. im Onlineshop Artikel vor, die einem auch gefallen könnten, oder im Streamingdienst Filme und Serien, die aufgrund bereits geschauter Titel wahrscheinlich ebenfalls den Geschmack des Zuschauers treffen. Doch auch in vielen sicherheitskritischen Bereichen, in denen es um Menschenleben geht, ist Software involviert. Sind wir Entwickler uns der daraus erwachsenden Verantwortung auch immer bewusst?
Mehr

Einer der größten Vorteile von Java ist das reichhaltige Ökosystem, in dem viele Bibliotheken und Frameworks für die Programmiersprache existieren. Auch der Bereich Logging hat gleich mehrere Frameworks zu bieten, was die Frage aufwirft, welches davon man nutzen soll. Dieser Artikel stellt die Frameworks kurz vor und soll als Entscheidungshilfe bei der Auswahl des passenden Frameworks dienen.Mehr

In Zeiten der “Fake News” sollte man stets den Wahrheitsgehalt von dem hinterfragen was man liest – insbesondere an einem bestimmten Tag im Jahr, wie gestern einer war. :-)

Der JEP-472 und die Entfernung der neuen Date & Time API aus meinem gestrigen Beitrag waren natürlich frei erfunden. Spätestens beim Anklicken der Quellen-Links wäre dies klar geworden.

Tatsächlich ist die java.time-API ein Beispiel für sehr gutes Code Design. Unter anderem werden die folgenden Prinzipien darin konsequent eingehalten:Mehr

(Achtung! Bitte nach der Lektüre unbedingt auch diesen Folgebeitrag lesen!)

Wie Oracle verlauten ließ, soll die mit Java 8 eingeführte Date & Time API wieder aus Java entfernt werden (JEP-472, JEP = Java Enhancement Proposal).

Komplexe API

Wie es aussieht wird die neue API, die auf Joda-Time basiert, von der Entwicklergemeinde nicht angenommen. Grund dafür ist, dass die API übermäßig komplex ist und aus zu vielen Klassen und Interfaces besteht, was die Anwendung der API sehr unhandlich macht. Oft weiß man nicht, welche Klasse bzw. welches Interface man nun eigentlich verwenden soll.

Laut Umfrage einer repräsentativen Gruppe von Java-Entwicklern setzen lediglich 3,42% der Entwickler bereits die neue API ein. Zusätzlich würden 2,11% der befragten Entwickler die API einsetzen, “wenn sie irgendwann einmal die Zeit fänden, sich einzuarbeiten”. Über 90% antworteten, dass sie die von Anfang an enthaltene API mit Date und Calendar gewöhnt seien und sich nicht umstellen wollten.

Stimmen der Vordenker

Bereits im Vorfeld hatten sich Größen aus der Entwicklerszene negativ über die API geäußert. So schrieb Martin Fowler in seinem Bliki (Mischung aus Blog & Wiki): “Who wants to learn an API with that many classes and interfaces? We had all we needed before Java 8, with Date and Calendar from the java.util package. And all experienced Java developers know how to use them and what their pitfalls are.”

Robert C. Martin, auch bekannt als “Uncle Bob”, twitterte: “It’s nearly impossible to write clean code with the Java 8 Time API”.

Brian Goetz, Java Language Architekt bei Oracle, begründete die Entscheidung damit, dass es den Aufwand nicht wert sei, eine Bibliothek zu pflegen, die so gut wie gar nicht genutzt würde. Weiter meinte er, “Finally with Java 9, we started to actually remove old stuff from the JDK. Why shouldn’t we also throw away newer libraries that aren’t actually used much? And for those who really need something like it, there’s stil Joda-Time.”

Weiteres Vorgehen

Wie geht es nun weiter? Zunächst sollen alle Klassen der API als “deprecated” markiert werden. Das wird laut JEP-472 bereits in Java Version 13 der Fall sein, die im Herbst 2019 erscheint. Endgültig entfernt werden sollen die Klassen in der nächsten LTS-Version 17, die ab Herbst 2021 verfügbar sein wird. So haben alle, die die neue API schon einsetzen, genug Zeit, ihre Anwendungen wieder auf die herkömmlichen Klassen zurück zu migrieren.

Ich selber finde es schade, da ich mich mittlerweile recht gut an die neue API gewöhnt habe :-(

Quellen:

jaxEnter-Artikel: Die Java Time API soll wieder weg!

JEP-472

Seit dem Erscheinen von Java 11 ist schon wieder ein halbes Jahr vergangen. Gemäß dem neuen Releasezyklus bedeutet dies, dass das nächste Major Release vor der Tür steht. Am morgigen Dienstag, den 19.03.2019 ist es wieder soweit: Java 12 wird öffentlich verfügbar.Mehr

Bereits im Jahr 2012 hielt Rich Hickey, der Erfinder der Sprache Clojure, auf der jax San Francisco eine Keynote über den “Wert von Werten”. In dem sehr unterhaltsamen, noch immer aktuellen Vortrag erläutert er, wieso das Verwenden von immutable value objects eine gute Idee ist, und stellt die Frage, wieso wir immer noch PLOP praktizieren (was das ist erklärt er im Video ;-)Mehr

Auf Github gehört es zum guten Ton, im Wurzelverzeichnis des Projekts eine README-Datei abzulegen. Darin beschreibt man wozu das Projekt gut ist, wie man es baut,  nutzt, u.s.w. In der Regel heißt die Datei README.md . Die Dateiendung .md sagt aus dass es sich um eine Markdown-Datei handelt.

Mehr