Für den Entwickler. Aber eben nicht jeder Kompilierer
Diese Unterscheidung kenne ich im Delphi-Umfeld nicht. Im Linux-Umfeld ist es in der Tat eher die Regel. Nur warum soll ich als Entwickler auf hilfreiche Tools verzichten? Du als Kompilierer machst doch eh nur "make", sonst wärst Du ja Entwickler
Ich bin ja Entwickler - aber als rücksichtsvoller Entwickler achte ich eben darauf, dass der Kompilierer es einfach hat, und eben tatsächlich sich nicht weit einzuarbeiten braucht. Make nimmt da schon sehr viel ab. Autoconf noch mehr.
Aber ich gebe gern zu, dass der Fall im Delphi-Umfeld bisher eher weniger die Regel ist.
Ich will doch gar nicht, dass du auf deine Tools verzichtest. Ich nutze doch auch welche (auch wenn sie anders aussehen). Dagegen sage ich doch gar nichts
Zitat:
Zitat:
Das Einhalten von Konventionen erschließt sich nicht jedem und so ist nicht nur in Delphi Clean Code ein ständiges Thema.
Bitte, wo ist diese Konvention schriftlich festgehalten?
Informiere Dich bitte selbst über Sinn und Zweck der Interface/Implemention-Sektionen.
Der Sinn dieser Trennung ist es, nur das an andere Module (Hauptprogramme, Units, Packages, Libraries) zu veröffentlichen, was auch tatsächlich veröffentlicht werden soll, und nicht jede kleine Fitzelroutine, die nur unitintern gebraucht wird.
Aber bei Dependencies geht es nicht um Veröffentlichung. Sondern um Abhängigkeiten der ganzen Datei bzw. sogar des ganzen Projekts.
Bei Uses-Klauseln in interface- und implementation-Teil sieht es in der Hinsicht aber genau gleich aus, was rechtfertigt dann die Unterscheidung?
Zitat:
Und was bitte hat das mit Clean Code zu tun? Solche Abhängigkeiten beziehen sich auf das ganze Projekt! Das ganze Projekt kompiliert ohne sie nicht.
Konventionen und auch Clean Code haben nichts damit zu tun, ob etwas kompiliert. Diesen Zusammenhang hast Du eingeführt.
Ich denke mit Clean Code meinen wir beide in diesem Kontext, dass man etwas nur dort deklariert, wo man es auch benötigt. Eine kleine Zählervariable deklariere ich lokal, weil der Bezug die jeweilige Routine ist.
Uses-Klauseln beziehen sich effektiv aber auf das gesamte Projekt, weil das gesamte Projekt diese Dependencies tatsächlich benötigt, auch wenn ich nur in einer oder zwei Routinen tatsächlich von den externen Klassen/Routinen Gebrauch mache,