Besser lesbare Schleifen

[ruderphilipp]

Durch das verbesserte for-Konstrukt für Schleifen wird der Code verständlicher. Mit Collections.addAll() wurde weiterhin der individuelle Code durch Standardmethoden ersetzt, um das Fehlerpotential zu senken.

[meigelb]

Bei Deinem Rebase ist folgender Commit verloren gegangen (siehe Dein Kommentar oben https://github.com/willuhn/hibiscus/pull/78#pullrequestreview-850836160): --------------8<-------------- Revision: 553da561083a4b2c449463af18a5605098033c60 Author: Philipp Riemer [email protected] Date: 28.11.2021 15:55:34 Message: Bugfix: aktuellen Dateinamen im Logging

Es wurde stets der erste Dateiname verwendet, wenn das Einlesen einer Datei nicht funktioniert hat, und nicht der Name der Datei, die die Fehler verursacht hat.

Modified: src/de/willuhn/jameica/hbci/gui/controller/LicenseControl.java -------------->8--------------

Randnotiz: Ich finde einen Rebase während aktivem Review immer etwas ungünstig, da ich dann unter Umständen alles erneut anschauen muss, anstelle nur den Diff der neusten Commits mit den Änderungen zu bewerten.

[ruderphilipp]

Hallo @meigelb,

Bei Deinem Rebase ist folgender Commit verloren gegangen [...] Es wurde stets der erste Dateiname verwendet, wenn das Einlesen einer Datei nicht funktioniert hat, und nicht der Name der Datei, die die Fehler verursacht hat. Modified: src/de/willuhn/jameica/hbci/gui/controller/LicenseControl.java

Das liegt daran, weil @willuhn die Codeanpassung bereits hinzugefügt hat (siehe 87c7c38d546d0b38e3c30b575155c5cd78d4e60f). Somit ist sie hier nicht mehr notwendig. :grinning:

Randnotiz: Ich finde einen Rebase während aktivem Review immer etwas ungünstig, da ich dann unter Umständen alles erneut anschauen muss, anstelle nur den Diff der neusten Commits mit den Änderungen zu bewerten.

Aus meiner Sicht ist ein Rebase deutlich übersichtlicher als ein Aufräumen mit zusätzlichen Commits, solange es sich noch um ein Pullrequest handelt. Grund: Die Änderungen sind noch nicht im Produkt/ Produktivcode ist, sondern erstmal ein Entwurf/ Kandidat -- somit kann man daran feilen und polieren bis es passt, ohne dass nachher im Produktivcode in der Historie das Hin und Her rekonstruiert werden können muss. Dort ist dann nur das Endergebnis ersichtlich (vgl. Punkt 10 hier).

Github unterstützt das, indem diejenigen Dateien im Reiter "Files changed" hervorgehoben werden, die sich geändert haben. Bei einem neuen Commit nach Deinem Review, wird jede veränderte Datei wieder aufgeklappt, der Haken bei "viewed" wird herausgenommen und ein Hinweis mit "changed since last view" erscheint.