Reihenfolge der Klassenmitglieder im Quellcode

Question

Dies war vorher gefragt (Frage Nr. 308581) aber diese spezielle Frage und die Antworten sind etwas C++-spezifisch und viele Dinge sind in Sprachen wie Java oder C# nicht wirklich relevant.

Die Sache ist die, dass selbst nach der Refaktorisierung, finde ich, dass es ein bisschen Chaos in meinem Quellcode-Dateien. Ich meine, die Funktionskörper sind in Ordnung, aber ich bin nicht ganz zufrieden damit, wie die Funktionen selbst angeordnet sind. Natürlich ist es in einer IDE wie Visual Studio relativ einfach, ein Element zu finden, wenn man sich erinnert, wie es aufgerufen wird, aber das ist nicht immer der Fall.

Ich habe einige Ansätze ausprobiert, wie z. B. öffentliche Methoden an die erste Stelle zu setzen, aber der Nachteil dieses Ansatzes ist, dass eine Funktion am Anfang der Datei am Ende eine andere private Funktion am Ende der Datei aufruft, so dass ich am Ende die ganze Zeit scrollen muss.

Ein anderer Ansatz besteht darin, verwandte Methoden zusammenzufassen (vielleicht in Regionen), aber das hat natürlich seine Grenzen, denn wenn es viele nicht verwandte Methoden in derselben Klasse gibt, ist es vielleicht an der Zeit, die Klasse in zwei oder mehr kleinere Klassen aufzuteilen.

Stellen Sie sich Folgendes vor: Ihr Code wurde ordnungsgemäß umstrukturiert, so dass er alle Anforderungen erfüllt, die in Code vollständig aber Sie möchten trotzdem Ihre Methoden neu ordnen für ergonomische Zwecke . Was ist Ihr Ansatz?

(Es handelt sich zwar nicht um ein technisches Problem, aber dieses Problem nervt mich gewaltig, so dass ich sehr dankbar wäre, wenn mir jemand eine gute Lösung vorschlagen könnte)

Answer 1

Vor ein paar Jahren habe ich viel zu viel Zeit damit verbracht, über diese Frage nachzudenken, und habe mir ein schrecklich komplexes System für die Anordnung der Deklarationen innerhalb einer Klasse ausgedacht. Die Reihenfolge hing von der Zugriffsspezifikation ab und davon, ob eine Methode oder ein Feld statisch, transient, flüchtig usw. war.

Das war es nicht wert. Meiner Meinung nach bringt eine so komplexe Anordnung keinen wirklichen Nutzen.

Was ich heute mache, ist viel einfacher:

1. Konstruktoren (Standardkonstruktor zuerst, ansonsten spielt die Reihenfolge keine Rolle).
2. Methoden, sortiert nach Namen (statisch vs. nicht-statisch spielt keine Rolle, auch nicht abstrakt vs. konkret, virtuell vs. final usw.)
3. Innere Klassen, sortiert nach Namen (Schnittstelle vs. Klasse etc. spielt keine Rolle)
4. Felder, sortiert nach Namen (statisch vs. nicht-statisch spielt keine Rolle). Optional Konstanten (public static final) zuerst, aber das ist nicht unbedingt notwendig.

Answer 2

Ich bin mir ziemlich sicher, dass es ein Visual Studio Addin gab, das die Klassenmitglieder im Code neu anordnen konnte.

also z.B. Koren an der Spitze der Klasse, dann statische Methoden, dann Instanzmethoden... so etwas in der Art

leider kann ich mich nicht mehr an den Namen dieses Addins erinnern! ich glaube auch, dass dieses Addin kostenlos war! vielleicht kann uns jemand anderes helfen?

Answer 3

Mein persönliches Konzept für die Strukturierung einer Klasse sieht folgendermaßen aus:

Ich bin streng mit

• Konstanten und statische Felder zuerst, in alphabetischer Reihenfolge
• nicht-private innere Klassen und Enums in alphabetischer Reihenfolge
• Felder (und ggf. Attribute), in alphabetischer Reihenfolge
• ctors (und ggf. dtors)
• statische Methoden und Fabrikmethoden
• Methoden, in alphabetischer Reihenfolge, unabhängig von der Sichtbarkeit.

Ich nutze immer die automatischen Formatierungsfunktionen einer IDE. Ich drücke also ständig auf Ctrl+Shift+F wenn ich arbeite. Ich exportiere die automatischen Formatierungsfunktionen in eine xml-Datei, die ich überallhin mitnehme.

Es hilft auf der Fahrspur beim Zusammenführen und Wiederaufnehmen. Und es ist die Art von Dingen, die Sie in Ihrer IDE oder Ihrem Build-Prozess automatisieren können, so dass Sie keine Gehirnzelle dafür schwitzen müssen.

Ich behaupte nicht, dass MEIN WEG ist der Weg. Aber wählen Sie etwas aus, konfigurieren Sie es, verwenden Sie es konsequent, bis es zu einem Reflex wird, und vergessen Sie es dann.