Juval Lowy's C# Coding Standards Fragen

Question

Ich genieße und empfehle sehr Juval Lowy's - C#-Codierungsstandard . Juval verzichtet ausdrücklich auf eine Begründung für jede Richtlinie, um den Standard straff zu halten (siehe Vorwort). Es gibt jedoch einige Richtlinien, bei denen ich neugierig bin, wie sie begründet werden.

Was ist die spezifische Begründung für die folgenden Richtlinien aus dem C#-Standard von Lowy?
Hoffentlich gibt es auf diese Fragen konkrete (nicht subjektive) Antworten.

1.13 Vermeiden Sie vollqualifizierte Typennamen. Verwenden Sie stattdessen die "using"-Anweisung.
Ist dies ein Leistungsproblem? Manchmal benötige ich nur eine Instanz des vollqualifizierten Namens und das Hinzufügen einer mit scheint schwer zu sein.

1.26 Verwenden Sie leere Klammern bei parameterlosen anonymen Methoden. Lassen Sie die Klammern nur dann weg, wenn die anonyme Methode auf jedem Delegaten hätte verwendet werden können.
Ich bin eigentlich nur durch den zweiten Satz verwirrt. Eine Erläuterung mit Beispiel(en) wäre hilfreich, danke.

2.19 Vermeiden Sie die Definition eigener Ausnahmeklassen
Welche Überlegungen gibt es, um ihre Zahl zu minimieren? (Als Nächstes gibt er Leitlinien an, wenn Sie sie definieren (in 2.20).

2.29 Vermeiden Sie die Verwendung des ternären Bedingungsoperators
Zu schwer für den Leser zu verdauen, oder andere Überlegungen?

2.31 Vermeiden Sie Funktionsaufrufe in booleschen bedingten Anweisungen. Weisen Sie sie lokalen Variablen zu und überprüfen Sie sie.
Ich glaube nicht, dass ich das tue, aber ich bin neugierig... warum nicht?

2.47 Vermeiden Sie Schnittstellen mit einem Mitglied.
Denn was ist immer/meistens vorzuziehen? Wann funktioniert eine Methodenschnittstelle?

2.53 Explizite Schnittstellenimplementierung bevorzugen
Warum? Auch, Jon Skeet ist hier anderer Meinung .

Vielen Dank im Voraus! Robert

Answer 1

2.29 Vermeiden Sie die Verwendung des ternären Bedingungsoperators Ich habe keine Probleme mit "einfachen" Verwendungen des ternären Operators, aber ich habe davon abgeraten, ihn in verschachtelter Form zu verwenden:

// This is fine
x := (conditionA) ? true_resultA : false_resultA;

// This would probably be clearer using if-then-elseif
x := (conditionA) ? 
       ((conditionA1) ? true_resultA1 : (condition2) ? true_result2 : false_result2) :
       ((conditionA2) ? true_resultA2 : false_resultA2);

Answer 2

Offensichtlich bin ich nicht Juval, aber ich kann es versuchen

1.13 Vermeiden Sie vollqualifizierte Typennamen. Verwenden Sie stattdessen die "using"-Anweisung.

Die Leistung kann hier nicht das Problem sein. Ich bin sicher, das Problem ist die Lesbarkeit.

1.26 Verwenden Sie leere Klammern bei parameterlosen, anonymen Methoden. Lassen Sie die Klammern nur dann weg, wenn die anonyme Methode auf jedem Delegaten hätte verwendet werden können.

public delegate void Foo1();
public delegate void Foo2(int val);

public void Foo()
{
    Foo1 first = delegate { Console.WriteLine("Hello world"); };
    Foo2 second = delegate { Console.WriteLine("Hello world"); };
    Foo1 third = delegate() { Console.WriteLine("Hello world"); };
    Foo2 fourth = delegate() { Console.WriteLine("Hello world"); }; // does not compile
}

Ohne die Parens kann der anonyme Delegat auf jeden Delegaten angewendet werden. Mit den Parens, sind Sie spezifisch über die Signatur des Delegaten. Bevorzugen Sie die zweite Syntax, es sei denn, Sie wirklich brauchen die Flexibilität.

2.19 Vermeiden Sie die Definition eigener Ausnahmeklassen

Auch hier geht es um die Lesbarkeit. Die Ausnahmeklassen des Frameworks sind reichhaltig und werden gut verstanden. Seien Sie vorsichtig, wenn Sie sie ersetzen.

2.29 Vermeiden Sie die Verwendung des ternären Bedingungsoperators

Das ist eine Sache der Lesbarkeit und der Erweiterbarkeit. Ich stimme dem nicht wirklich zu, aber es ist ein üblicher religiöser Streit.

2.31 Vermeiden Sie Funktionsaufrufe in booleschen bedingten Anweisungen. Weisen Sie sie lokalen Variablen zu und überprüfen Sie sie.

Zum Teil geht es um die Lesbarkeit, zum Teil um eine einfachere Fehlersuche. Ich habe damit begonnen, fast alles temporären Variablen zuzuweisen, damit sie später im Debugger leicht zu finden sind.

2.47 Vermeiden Sie Schnittstellen mit einem Mitglied.

"Vermeiden" ist so etwas wie "bevorzugen", er will damit nur sagen, dass man es sich zweimal überlegen soll, bevor man es tut. Wenn Sie nur ein Mitglied haben, modelliert die Schnittstelle dann wirklich etwas Nützliches und Vollständiges in Ihrem Design? Es ist ziemlich selten, eine Klasse mit nur einem Mitglied zu haben, denken Sie ernsthaft darüber nach, warum Ihre Schnittstelle etwas anderes ist.

2.53 Explizite Schnittstellenimplementierung bevorzugen

Dies ist vergleichbar mit der Idee, den am wenigsten öffentlichen Accessor zu verwenden. Wenn Ihre Klasse nicht brauchen um die Schnittstelle öffentlich zu machen, dann sollte sie wahrscheinlich nicht verwendet werden. Das hängt natürlich stark von Ihrem Design ab, aber angesichts der Tatsache, dass die meisten Leute die Schnittstelle einfach implizit machen, ohne wirklich darüber nachzudenken, ist das ein Rat, den man in Betracht ziehen sollte.

Answer 3

1.26 geht es um Prä-Lambda delegate { } Syntax.

// #1 Empty parenthesis on parameterless-anonymous methods would be:
delegate() { }
// #2 ... anonymous method could have been used on any delegate, is:
delegate { }

Vergessen Sie nicht, dass letztere zugewiesen werden können cualquier Delegaten, unabhängig von dessen Parametern. Der Delegat ignoriert diese einfach mit Hilfe eines Compiler-Tricks.

Wenn Sie einen Delegaten definieren, der keine Parameter benötigt, sagen Sie dies ausdrücklich mit #1. Lassen Sie nicht "die Klammern weg, weil Ihr Delegat sowieso keine Parameter annimmt".

Answer 4

Viele dieser Leitlinien beziehen sich auf die "Qualitätsmerkmale" eines guten Softwaredesigns (d.h. Wartbarkeit, Zuverlässigkeit, Wiederverwendbarkeit, Testbarkeit, Erweiterbarkeit, Fehlersuchbarkeit, Interoperabilität und was man sonst noch alles nennen kann).

Oft wird Code erstellt, der im Moment gut funktioniert, aber unter Berücksichtigung aller Qualitätsmerkmale nicht die beste Wahl ist (im Sinne von "Wohin kann diese Software gehen? in Zukunft " oder "jemand anderes muss diesen Code auch benutzen").

Zum Beispiel:

2.29 Vermeiden Sie die Verwendung des ternären Bedingungsoperators

Ich habe kein Problem mit ternären Ausdrücken, per se sondern durch das Schreiben von Code wie: int result = CheckMethod() ? OnTrueDoThis() : OnFalseDoThat() ... Sie sagen: "Ich habe eine Bedingung, die, wenn sie wahr (oder falsch) ist, Sie tun können eine und nur eine Sache ." Das ganze Konstrukt erschwert die Erweiterbarkeit . Sie müssen das Konstrukt neu erstellen (mit einer if..else-Anweisung).

Ähnlich...

2.31 Vermeiden Sie Funktionsaufrufe in booleschen bedingten Anweisungen. Zuweisen in lokale Variablen und prüfen Sie diese.

Sie haben eine Funktion aufgerufen und im Wesentlichen die Ergebnisse "verworfen" hat zur späteren Verwendung. Wenn diese Informationen später benötigt werden, müsste entweder die Funktion erneut aufgerufen oder die Struktur des Codes umgeschrieben werden. Dies würde auch die Überprüfung oder Protokollierung der Ergebnisse (für die spätere Fehlersuche) erschweren.

Answer 5

Zu 1.13 (Vermeiden Sie voll qualifizierte Typnamen. Verwenden Sie stattdessen die "using"-Anweisung):

Es kann etwas mehr sein als nur die Lesbarkeit. Wenn Sie zu viele Verwendungen am Anfang der Datei haben, haben Sie eine Klasse, die mit Klassen aus zu vielen Namespaces gekoppelt ist.

Die Klasse schreit förmlich nach einer Überarbeitung. Durch die Verwendung von Usings anstelle von vollqualifizierten Klassennamen können Sie solche eng gekoppelten Klassen leichter identifizieren.