Uses: Interface vs. Implementation Section

[neo4a]

Zitat:

Zitat von implementation (Beitrag 1142430)

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:

Zitat von implementation (Beitrag 1142430)

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:

Zitat von neo4a (Beitrag 1142438)

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:

Zitat von neo4a (Beitrag 1142467)

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. :roll:

[neo4a]

Zitat:

Zitat von implementation (Beitrag 1142470)

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:

Zitat von implementation (Beitrag 1142470)

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:

Zitat von implementation (Beitrag 1142470)

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:

Zitat von implementation (Beitrag 1142470)

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:

Zitat von neo4a (Beitrag 1142476)

Zitat:

Zitat von implementation (Beitrag 1142470)

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 :-D

Zitat:

Zitat:

Zitat von implementation (Beitrag 1142470)

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:

Zitat von implementation (Beitrag 1142470)

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,

[Furtbichler]

Zitat:

Zitat von implementation (Beitrag 1142430)

Dann ist es doch viel einfacher und schneller, einfach oben im interface-Abschnitt zu schauen

. Nee, ganz sicher nicht schneller. Den Compiler gegen die Wand fahren lassen, ist am schnellsten. Schon soo oft machen müssen. Soll ich bei einem fremden Projekt etwa erst alle Uses-Klauseln analyiseren? Ja bin ich denn bescheuert? F9 und fertig. Wenns passt, dann Ctrl+F9, bis es passt. Wobei ich mich ab -sagen wir- 5.000.000 Codezeilen umorientieren würde. Vielleicht.

Zitat:

Zitat von implementation (Beitrag 1142430)

"Ausprobieren und den Compiler in den Fehler laufen lassen, dann wird man schon sehen, was er nicht findet" - denn das ist jawohl die unsauberste Methode überhaupt.

WTF. Das Resultat ist 100% das gleiche, wenn nicht sogar optimaler, denn so habe ich garantiert keine unnütze Unit eingebunden.

Dein Vergleich mit dem Code ist zwar stark hinkend aber auch nicht blöd. Denn Exceptions sind doch der OOP, oder? :stupid:

Im Übrigen ist 'gegen die Wand fahren lassen' ein anerkanntes Preventive-Maintenance-Werkzeug und nicht so leicht zu verbessern.

Dein Argument mit den 1000 Zeilen bis zum implementation kann ich aber nachvollziehen. Wer so etwas ständig machen muss, wünscht sich, das die benötigten Units alle oben stehen. Na ja, dann soll er doch. Einfach den GExperts Uses Clause Manager starten, alle Units ins Interface verschieben, fertig.

Eins noch:
Die Units im Interface-Teil helfen, die Bedeutung der Unit im Kontext des Systems zu verstehen. Werden hier auch Units aufgelistet, die nur in der Implementierung benötigt werden, irritiert das. Was interessiert es mich, das der TCP-Wrapper mit ICS umgesetzt wurde (oder was weiss ich).

Was ist denn nun klarer?

Delphi-Quellcode:

Unit MyUnit;
Interface
uses BarDefinition;

Function AnExtremelyTrickyCalculation(SomeParameters : TBar) : Extended;

implementation
uses Wow, HardCore, DirtyStuff, EvenMoreDirtyStuff, PetersTricks, MikesHacks, DontPublishThis, VerySecret;
...

oder

Delphi-Quellcode:

Unit MyUnit;
Interface
uses BarDefinition, Wow, HardCore, DirtyStuff, EvenMoreDirtyStuff, 
  PetersTricks, MikesHacks, DontPublishThis, VerySecret;

Function AnExtremelyTrickyCalculation(SomeParameters : TBar) : Extended;

implementation
...

Also von der Seite aus betrachtet, würde ich den Autor der 2.Variante vierteilen.


So wie ich das sehe gibts hier zwei Meinungen:
Die Praktiker sagen "Alle Units nach oben, sonst kriech ich Augenkrebs"
Die Ästheten sagen "Alle Units da hin, wo sie hingehören, sonst kriech ich Augenkrebs"

Tja.

[neo4a]

Zitat:

Zitat von Furtbichler (Beitrag 1142482)

So wie ich das sehe gibts hier zwei Meinungen:
Die Praktiker sagen "Alle Units nach oben, sonst kriech ich Augenkrebs"
Die Ästheten sagen "Alle Units da hin, wo sie hingehören, sonst kriech ich Augenkrebs"

Ich bin weder kein Praktiker noch bin ich kein Ästhet, deshalb noch meine 3. Meinung:

Alle Units da hin, wo sie hingehören, weil
- es sich so gehört (Convention),
- es für mich und andere leichter zu verstehen und zu warten ist (Clean Code),
- es eine Form der Inline-Doku ist (Best Practice),
- jede Unit-Referenz im Interface-Teil genau hinterfragt gehört (Law of Demeter)

Und weil unsere Delphi-Welt so liberal ist, muss man keine der o.g. Gründe akzeptieren und es kompiliert trotzdem: Ist das nicht herrlich?!

[brechi]

Zitat:

Zitat von neo4a (Beitrag 1142485)

Zitat:

Zitat von Furtbichler (Beitrag 1142482)

So wie ich das sehe gibts hier zwei Meinungen:
Die Praktiker sagen "Alle Units nach oben, sonst kriech ich Augenkrebs"
Die Ästheten sagen "Alle Units da hin, wo sie hingehören, sonst kriech ich Augenkrebs"

Ich bin weder kein Praktiker noch bin ich kein Ästhet, deshalb noch meine 3. Meinung:

Alle Units da hin, wo sie hingehören, weil
- es sich so gehört (Convention),
- es für mich und andere leichter zu verstehen und zu warten ist (Clean Code),
- es eine Form der Inline-Doku ist (Best Practice),
- jede Unit-Referenz im Interface-Teil genau hinterfragt gehört (Law of Demeter)

Und weil unsere Delphi-Welt so liberal ist, muss man keine der o.g. Gründe akzeptieren und es kompiliert trotzdem: Ist das nicht herrlich?!

Richtig, ist deine Meinung. Mehr aber auch nicht.

"Alle Units da hin, wo sie hingehören, weil
- es für mich und andere leichter zu verstehen und zu warten ist (Clean Code)"

ich bin jetzt der "andere", für mich ist es nicht leichter zu warten, man muss erst die units suchen, wenn diese schoen sortiert und nach externen bilbiotheken getrennt oben stehen ist das fuer mich leicht zu verstehen:

Delphi-Quellcode:

  uses
    windows, classes, sysutils, // delphi
    fastreport, fastscript, fastirgendwas // fastreport: libs/fastreport/src
    teechart, teetools; // teechart: libs/teechart/src

Einfach zum Einbinden in andere Projekte. Da muss ich nicht immer den Compiler gegen die Wand fahren lassen.