Uses: Interface vs. Implementation Section

[neo4a]

Zitat von implementation:

Bisher geht ihr alle davon aus, dass ihr/eure Firma/euer Entwicklerteam die einzigen seid, die das Projekt kompilieren.

Wie kommst Du denn nur darauf?

Zitat von implementation:

Dann ist es doch viel einfacher und schneller, einfach oben im interface-Abschnitt zu schauen, gerade weil diese Klausel direkt sehr weit oben im Code ist. Man bedenke, dass der interface-Abschnitt gerne mal >200 Zeilen lang werden kann, und dementsprechend die implementation-uses-Klausel irgendwo mitten im Code liegt (erstmal finden!)

Gut. Du hast also (manchmal) Schwierigkeiten, Dich in umfangreichen Code zurecht zu finden. Kann ja mal vorkommen, auch ohne Clausthaler.

Warum benutzt Du dann nicht IDE-Tools wie die Editor-Toolbar von CnPack, die Dir nicht nur per Klick die Units listet, sondern auch noch den Sprung zu den Sektionen per Maus- oder Tastatur-Klick bietet, nicht zu reden von der einfachen Navigation zu den Prozeduren?

Neben dem bereits erwähnten Unit Cleaner ebenfalls eine sinnvolle Erweiterung vom CnPack, von dem ich wirlich nur ein halbes Dutzend Funktionen aktiviert habe.

[implementation]

Zitat von neo4a:

Warum benutzt Du dann nicht IDE-Tools wie die Editor-Toolbar von CnPack, die Dir nicht nur per Klick die Units listet, sondern auch noch den Sprung zu den Sektionen per Maus- oder Tastatur-Klick bietet, nicht zu reden von der einfachen Navigation zu den Prozeduren?

Neben dem bereits erwähnten Unit Cleaner ebenfalls eine sinnvolle Erweiterung vom CnPack, von dem ich wirlich nur ein halbes Dutzend Funktionen aktiviert habe.

Solche lustigen Tools hast du als Entwickler der Software vllt., aber nicht jeder, der das Projekt nur mal eben auf seiner Zielplattform kompilieren will, und das kann man dann auch nicht erwarten.

----
Gut. Ich gebe zu, das ganze kommt in Delphi selten vor, da jeder, der nur mal eben was fremdes kompilieren will, sich erstmal teuer Delphi kaufen muss, und wenn mans dann hat, hat man ja schon gleich ne Mega-IDE. Und letztendlich ist dort die Auswahl an Zielplattformen ja doch nicht so groß, dass das Szenario überhaupt Sinn macht.

Aber ich sags mal so: Ich arbeite schon eine ganze Weile mit dem FPC, und da öffnen sich nunmal ganz neue Möglichkeiten: denn auf einmal laufen Programme auch auf SPARC, PowerPC, ARM, Alpha und Co. Und als Entwickler kann ich das nunmal schlecht für jede CPU-Typ/Betriebssystem-Kombination kompilieren. Gängige Praxis ist es im GNU/Linux-Umfeld daher sowieso längst, vieles erst auf dem Zielsystem zu kompilieren. Und genau den Fall habe ich hier betrachtet.

Angenommen ich habe ein FreeBSD auf SPARC am laufen, muss ich jegliche Fremdsoftware von andern nunmal erst selbst kompilieren. Das ist so und ergibt sich bereits aus der Natur der Tatsache, dass es überhaupt soviele verschiedene Plattformen gibt. Und als Entwickler will man dies doch möglichst einfach machen. Und solche Aktionen, wie für den Kompilierer wichtige Abschnitte quer durch den Code zu verstreuen, ohne dass sich ein nennenswerter Vorteil ergibt, sind absolut kontraproduktiv.

[neo4a]

@implementation

Es steht Dir frei, Tools als lustig zu beurteilen. Das kommt immer gut, ist lässig und zeigt nur denen, die die Tools praktisch nutzen und es somit besser wissen, dass Du davon nur wenig verstehst. Leider ist die Delphi IDE nicht von Haus aus komplett und so braucht man Erweiterungen wie GExpert, VersionInsight, CnPack, AQTime, MadExecept. Das Konzept kennt man auch aus anderen IDEs. Und nicht nur ich finde: Gutes Werkzeug ist durch nichts zu ersetzen!

Schau bitte in meinen Post 28 in diesem Thread für eine Erklärung, warum es klar ist, wann welche Sektion für eine Unit-Referenz verwendet wird. Ob Du das für Dich auch nachvollziehen kannst, spielt dabei eigentlich keine Rolle. Das Einhalten von Konventionen erschließt sich nicht jedem und so ist nicht nur in Delphi Clean Code ein ständiges Thema.

Dass Du mit FP und Linux noch etwas andere Sichtwinkel und Einsatzbereiche hast und i.d.R. ohne Delphi-IDE auskommen musst, ändert am Sinn der Konventionen eigentlich gar nichts.

[implementation]

Zitat von neo4a:

Es steht Dir frei, Tools als lustig zu beurteilen. Das kommt immer gut, ist lässig und zeigt nur denen, die die Tools praktisch nutzen und es somit besser wissen, dass Du davon nur wenig verstehst. Leider ist die Delphi IDE nicht von Haus aus komplett und so braucht man Erweiterungen wie GExpert, VersionInsight, CnPack, AQTime, MadExecept. Das Konzept kennt man auch aus anderen IDEs. Und nicht nur ich finde: Gutes Werkzeug ist durch nichts zu ersetzen!

Das "lustig" sollte die Tools auf keinen Fall abwerten. Natürlich sind sie für den Entwickler durchaus sehr praktisch.
Für den Entwickler. Aber eben nicht jeder Kompilierer, der das fremde Programm nur auf seiner eigenen Plattform zum laufen bringen will, will sich damit aufhalten, noch zig Add-Ins und Tools zu installieren.

Zitat:

Schau bitte in meinen Post 28 in diesem Thread für eine Erklärung, warum es klar ist, wann welche Sektion für eine Unit-Referenz verwendet wird. Ob Du das für Dich auch nachvollziehen kannst, spielt dabei eigentlich keine Rolle.

Genannter Post überzeugt mich nicht im geringsten. Die uses-Klausel im implementation-Bereich halte ich für überflüssig.

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? Ich glaube mittlerweile eher, man hat diese Möglichkeit damals lediglich für Kreisreferenzen eingeführt, und versucht nachträglich, dem ganzen mehr Sinn einzuhauchen.

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. Selbst wenn nur eine einzige Prozedur es benutzt, der effektive Bezug ist immer noch das volle Projekt, nicht die Codedatei und nicht der einzelne Abschnitt. Das ist auch der Grund, weshalb MS das im VS anders gelöst hat: Assemblies werden dort immer für das ganze Projekt zentral eingebunden.
In Delphi ist das anders, und die gängige Praxis mag anders sein. Aber das heißt nicht, dass sie besser, geschweige denn "cleaner" ist, nur weil sie vorgibt, sich auf einen kleineren Bereich zu beziehen (es schlussendlich aber nicht tut).

Zitat:

Dass Du mit FP und Linux noch etwas andere Sichtwinkel und Einsatzbereiche hast und i.d.R. ohne Delphi-IDE auskommen musst, ändert am Sinn der Konventionen eigentlich gar nichts.

Es geht nicht um mich als Entwickler, sondern um den Nutzer, der das ganze nachkompilieren will, um auch was davon zu haben.

[himitsu]

Ach ja, nur weil Delphi selber neuerdings Einiges in der Implementation einfügt, heißt noch lange nicht, daß sie sich dabei was gedacht haben.
Und auch zu sagen "schau mal, in dieser VCL-Unit ist das auch so" ... es sollte jeder bemerkt haben, daß die VCL an vielen Stellen nicht grade konsequent ist.

[neo4a]

Zitat von implementation:

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

Zitat von implementation:

Zitat:

Schau bitte in meinen Post 28 in diesem Thread für eine Erklärung, warum es klar ist, wann welche Sektion für eine Unit-Referenz verwendet wird. Ob Du das für Dich auch nachvollziehen kannst, spielt dabei eigentlich keine Rolle.

Genannter Post überzeugt mich nicht im geringsten.

Damit kann ich leben.

Zitat von implementation:

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.

Zitat von implementation:

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.

[implementation]

Zitat von neo4a:

Zitat von implementation:

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 von implementation:

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:

Zitat von implementation:

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,