ReSharper und StyleCop vs. die Step-down-Regel (Clean Code)

9

Ich kann mir vorstellen, dass dies ein ziemlicher Spagat ist, aber es ist etwas, für das ich seit einiger Zeit Probleme habe, es zu formulieren, und ich möchte es der breiteren Entwicklungsgemeinschaft vorstellen.

Ich arbeite in einer Rolle, in der wir vor dem Einchecken einer Datei das automatische ReSharper-Format-Tool ausführen, das Dinge in Regionen nach Zugriffsmodifizierer gruppiert und die darin enthaltenen Elemente alphabetisch sortiert. Es folgt im Wesentlichen dem in diesem Beitrag beschriebenen Klassenlayoutmuster: Alphabetisierungsmethoden in Visual Studio , an denen die Leute sehr interessiert sind.

Ich bin glücklich, mit allen Coding-Standards zu arbeiten, aber ich bemühe mich, diesen Ansatz mit dem Schreiben von sauberem Code in Einklang zu bringen, vor allem, weil ich mich streng an die Step-Down-Regel halte (Robert C Martin - Clean Code) und das Alphabetisieren bricht das.

Die Abwärtsregel wird wie folgt beschrieben:

Wir möchten, dass der Code wie eine Top-down-Erzählung gelesen wird. Wir wollen, dass jeder Funktion auf der nächsten Abstraktionsebene gefolgt wird, so dass wir das Programm lesen können, indem wir eine Ebene der Abstraktion auf einmal herunterfahren, während wir die Liste der Funktionen durchlesen. Ich nenne das die Step-Down-Regel. Die ideale Anzahl von Argumenten für eine Funktion ist Null. Als nächstes kommt einer. Dann zwei. Drei Argumente sollten nach Möglichkeit vermieden werden.

Nach diesem Ansatz könnte ich den folgenden (erfundenen) Code schreiben:

%Vor%

Wenn ich dann das automatische Format ausführe, sehe ich am Ende folgendes (Kommentare entfernt):

%Vor%

Nun, ich finde den zweiten Stil auf den ersten Blick viel schwerer zu verstehen, und ich finde es ungewöhnlich, die Lesbarkeit des ersten Stils innerhalb der Grenzen des zweiten zu bewahren. Dazu gehören:

  • Präfix der Eignermethode - d. h. ConfigureClearState, ConfigureUnpackData, AggregateRecordsCalculateGroupings, AggregateRecordsPopulateGroups, usw. Dies führt zu langen Membernamen, insbesondere wenn die "Owned" -Methoden zusätzliche 'eigene' Methoden benötigen.
  • De-factoring - Verschieben von Code aus kleinen Methoden, die ich ursprünglich refaktorisiert habe, zurück in die Methode, aus der er stammt. Was zu langen Methoden führt.
  • Partielle Klassen - Ich bin noch nicht wirklich zu diesem Punkt gekommen, aber es ist durchaus möglich, dass ich verwandte Methoden in Teilklassen einteile, um sie vom Hauptteil des Codes zu trennen. Das füllt den Lösungs-Explorer mit Haufen von Code-Dateien.

Natürlich bin ich mit keinem dieser Ansätze zufrieden, aber soweit ich sehen kann, sind sie die einzigen echten Optionen, um die Lesbarkeit innerhalb der Betriebsparameter zu erhalten.

Anscheinend ist der zweite Ansatz der Microsoft-Hausstil, also meine Frage (n) wäre:

  • Stimmt es, dass der zweite Ansatz der Microsoft-Hausstil ist?
  • Wenn ja - wie behält Microsoft sauber lesbaren Code im zweiten Stil bei?
  • Ist jemand anders auf diese Disparität gestoßen, und welche Ansätze haben die Leute benutzt, um eine gute Lesbarkeit zu erreichen?
  • Was sind die allgemeinen Stileinstellungen für das Schreiben von sauberem Code?

Ich habe eine Kopie des Microsoft-Codierungsstils gefunden: Ссылка

    
Tristan Rhodes 19.02.2014, 13:14
quelle

1 Antwort

3

Der Ansatz von Robert Martin zielt auf Lesbarkeit. Um die Vorteile in vollem Umfang genießen zu können, müssen Sie zusätzliche Konventionen oder Regeln anwenden (z. B. Namensgebung, Verzicht auf Kommentare zur Auswahl aussagekräftiger und beschreibender Namen, Einzelverantwortung, kurze Methoden, ...). Dann können Sie Ihren Code wie ein gewöhnliches Textdokument lesen. Wenn der nächste Funktionsblock der Abstraktionsebene eingerückt wird, verbessert dies auch die Lesbarkeit. Auf diese Weise können Sie Abstraktionsebenen nach Ihrem Code-Format ausdrücken:

%Vor%

Vielleicht werden Sie feststellen, dass Sie Ihr Mausrad missbrauchen, wenn Sie den alphabetischen Stil verwenden, um nur nach oben und unten zu blättern, um Ihren Kontext zu verstehen. Auf der anderen Seite müssen Sie beim Refactoring Ihres Codes keine Einrückungen und Abstraktionsebenen beibehalten.

Dies sind zwei verschiedene Ansätze mit unterschiedlichen Zielen. Man mag es, die Lesbarkeit zu verbessern (für Menschen), und Sie können Methoden über den Programmablauf finden, während der andere es liebt, Methoden schnell anhand ihres Namens zu finden. Die alphabetische Sortierung unterstützt die allgemeine Konvention, alle öffentlichen Methoden zusammenzufassen, was auch die Chance erhöht, den Zweck und das Verhalten einer Klasse (auf einen Blick) herauszufinden. Step-Down mischt gerne öffentliche und private Methoden nach einem anderen Ziel.

Sie können nicht beides haben. Also unter keinen Umständen Hunderte von Regeln verletzen und Refactoring auslassen, nur um diese beiden Stile zu vermischen. Macht keinen Sinn und macht den Code viel weniger lesbar.

Wenn Sie glauben, dass das Lesen des Step-down-Stils sich angenehmer und natürlicher anfühlt als das Lesen von Code in einem Wörterbuchstil, sollten Sie ihn verwenden. Das tue ich.

Ich habe noch nie von Microsoft-internen Konventionen wie dem alphabetischen Sortieren von Code gehört. Die offizielle .NET-Konvention zielt nicht auf eine Organisation oder Konvention für die Struktur des Codes ab (neben anderen wird empfohlen, den Ereignisdelegaten ganz oben in einer Klasse zu platzieren, usw.).

Die Step-Down-Regel ist nur ein inoffizieller Stil. Einige automatische Formatierungstools unterstützen keine Einzugsmethoden und platzieren sie auf einer Ebene.

Übrigens ist die Verwendung von partiellen Klassen, um schlechtes Design zu verschleiern (zu große Klassen / zu viel Verantwortung), keine Option für jemanden, der sich um sauberen und wartbaren Code kümmert.

Um die Dinge für Sie einfacher zu machen, würde ich versuchen, Ihrem Team den Vorteil Ihres Stils zu zeigen oder den Stil zu akzeptieren, den die Mehrheit Ihres Teams bevorzugt.

Vergessen Sie nicht, dass Ihre IDE Ihnen sehr hilft, indem Sie die Methoden in Ihrem Code hervorheben oder Funktionen wie "zur Implementierung gehen" oder "Verwendungen finden" oder Code-Maps verwenden, die die Reihenfolge der Methodenaufrufe anzeigen. Und es gibt sehr viel wichtigere Regeln für die Lesbarkeit von Codes wie gute Namen und gutes Design.

Ja, aber ich persönlich bevorzuge Step-down.

    
BionicCode 20.02.2014, 10:27
quelle