Unified vs. Split Diff

• Erläuterung der Vor- und Nachteile der Verwendung von Unified Diff und Split Diff beim Code-Review
• Unified Diff und Split Diff eignen sich für einfache und kleine Änderungen
• Für große und komplexe Änderungen sind weder Unified Diff noch Split Diff ideal
• Der Autor bevorzugt es, die gesamte Codebasis zu einem bestimmten Zeitpunkt zu überprüfen, sich dabei auf kürzlich geänderte Bereiche zu konzentrieren und zugleich eine allgemeine Durchsicht durchzuführen
• Als ideales Diff-View schlägt der Autor vor, links den aktuellen Zustand des Codes anzuzeigen und rechts den Unified Diff der aktuell sichtbaren Codebasis mit dezent hervorgehobenen Änderungen
• Es wird darauf hingewiesen, dass dieses Review-Format von bestehenden Tools, die sich eher auf die Prüfung von Diffs als von tatsächlichem Code konzentrieren, nicht gut unterstützt wird
• Der Autor nutzt für diesen Review-Stil einen Low-Tech-Workflow und verwendet lokal ein Skript, um Pull Requests zu prüfen. Dieses Skript entfernt alle Commits des Pull Requests, behält aber sämtliche Änderungen bei
• Der Workflow des Autors erleichtert das Navigieren durch geänderte Dateien und das Markieren überprüfter Hunks, bietet jedoch keine automatische Synchronisierung zwischen Statuspuffer und der aktuell im Editor geöffneten Datei
• Der Autor wünscht sich ein Tool, das das Reviewen von Code auf diese Weise erleichtert, ohne dass dafür ein maßgeschneidertes Ad-hoc-Tool gebaut werden muss
• Der Autor weist außerdem darauf hin, dass der Artikel zwar Methoden des Code-Reviews behandelt, das Hauptziel von Code-Review aber nicht zwingend darin besteht, den Code selbst zu prüfen, und verweist dazu auf einen verwandten Beitrag per Link

[GN⁺]

Hacker-News-Kommentare

• Dieser Artikel diskutiert die Unterschiede zwischen Unified Diff und Split Diff beim Code-Review.
• Einige Kommentatoren argumentieren, dass die Art des Reviews je nach Team und Ticket variiert; manche bevorzugen eine mentale Prüfung durch ein zweites Paar Augen, andere ein tiefgehendes, strukturiertes Review der Funktion vor dem Merge.
• Ein Tool namens difftastic wird erwähnt, das strukturelles Diffing für eine feinere Hervorhebung von Diffs verwendet.
• Einige Kommentatoren nutzen Skripting mit vim, um die in einem offenen PR zur Review anstehenden Änderungen zu prüfen.
• Die Schwierigkeiten von Code-Reviews in großen und komplexen Codebasen werden hervorgehoben; das Problem hängt eher mit Kultur und Wissensaustausch zusammen als mit den Tools.
• Es wird erwähnt, dass eine GitHub-Funktion, bei der man im Browser . drückt, um in eine vollständige IDE zu wechseln, nützlich ist, um Änderungen im Kontext der gesamten Datei zu betrachten.
• Einige Kommentatoren hinterfragen die Präferenz des Autors, im Split Diff unnötigen Kontext zu entfernen, während andere Funktionen anderer Tools wie p4merge vermissen.
• Es wird vorgeschlagen, GitHubs VSCode im Browser zu verwenden, um die Diff-Ansicht anzuzeigen und sowohl die gesamte Datei als auch komplexere Diffs lesbarer zu sehen.
• Meld wird als ein Tool vorgeschlagen, das für diese Anwendungsfälle gut funktioniert.