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

Dies ist mein bester Versuch, die von Ihnen aufgeführten Fragen zu beantworten. Diejenigen, die ich nicht wirklich beantworten kann, habe ich weggelassen.

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

Lesbarkeit. Es muss schwieriger sein, Code zu lesen, wenn man voll qualifizierte Typnamen lesen muss.

2.19 Vermeiden Sie die Definition eigener Ausnahmeklassen

Das .NET-Framework verfügt über einen guten Satz von Ausnahmen, die in das System integriert sind. Sofern die Ausnahme, die Sie modellieren, nicht geschäftsspezifisch ist, können Sie wahrscheinlich eine der vorhandenen Ausnahmeklassen verwenden.

2.29 Vermeiden Sie die Verwendung des ternären Bedingungsoperators

Ich denke, das liegt wahrscheinlich daran, dass er glaubt, die Leute würden den Betreiber nicht verstehen, aber da bin ich anderer Meinung.

2.47 Vermeiden Sie Schnittstellen mit einem Mitglied.

Er könnte die Leute davor warnen, Schnittstellen zu bauen, die zu dünn sind. Ich würde jedoch eher das Gegenteil behaupten und die Leute davor warnen, Schnittstellen zu langatmig zu gestalten. Wenn Sie jemals mit ASP.NET MembershipProvider zu tun hatten, wissen Sie, wovon ich spreche.

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

Hier fallen mir mehrere Gründe ein. Die Lesbarkeit. Es kann schwierig sein, bedingte Anweisungen zu verstehen, wenn Sie darin Funktionsaufrufe machen. Außerdem ist es schwieriger zu debuggen, wenn man nicht aufpasst.

2.53 Explizite Schnittstellenimplementierung bevorzugen

Ich glaube, er will sich hier kurz fassen. Allerdings stimme ich mit dieser Einschätzung nicht wirklich überein. Ich denke, Jon hat recht, implizite Schnittstellen sollten verwendet werden, wenn es möglich ist, und explizite, wenn es angemessen ist.

Answer 2

Hier sind einige meiner Reaktionen, auf die ich zu antworten wage :)

1.13 Vermeiden Sie vollständig qualifizierte Typennamen. Verwenden Sie stattdessen die "using"-Anweisung. Ich bin anderer Meinung. Es hat sicherlich nichts mit der Leistung zu tun. Es peut zu einer besseren Lesbarkeit führen, um var foo = new Foo() stattdessen var foo = new MyCompany.MyNamespace.Helpers.Xml.Foo() aber ansonsten - nein.

2.19 Vermeiden Sie die Definition eigener Ausnahmeklassen Das ist imho Unsinn. Sie sollten es vermeiden, benutzerdefinierte Ausnahmen, die von ApplicationException ableiten, zu erstellen, aber es ist nichts falsch mit benutzerdefinierten Ausnahmen (solange Sie nicht gehen, um bestehende Ausnahmen neu zu erfinden, das heißt).

2.29 Vermeiden Sie die Verwendung des ternären Bedingungsoperators Ich habe keine Ahnung, warum das eine Leitlinie sein sollte. Ich habe gelesen, dass nicht alle Leute ihn verwenden und ihn vielleicht nicht erkennen, aber das ist kein gültiger Grund, einen nützlichen Operator nicht zu verwenden.

2.31 Vermeiden Sie Funktionsaufrufe in booleschen bedingten Anweisungen. Weisen Sie sie lokalen Variablen zu und überprüfen Sie sie. Meiner Meinung nach ist dies einfach ein Problem der Lesbarkeit.

2.47 Vermeiden Sie Schnittstellen mit einem Mitglied. Auch hier bin ich anderer Meinung. Man sollte allerdings "Marker"-Schnittstellen vermeiden - Schnittstellen ohne Marker, die nur dem Zweck dienen, dass etwas "...ble" ist. Aber eine Methode auf einer Schnittstelle scheint mir in Ordnung zu sein.

Answer 3

2.29 Ternärer Operator

Wenn Sie den ternären Operator verwenden, sollten Sie zunächst einen Grund für die Verwendung des ternären Operators im Vergleich zu einem normalen if-then-else-Operator finden. Beachten Sie:

if (x == 0) {...} else{...} //A set of statements demand a regular If-then-else

//A simple assignment can be handled by the ternary operator
y = (x == 0)? 1 : 0 //this is readable and how it should be used

(x==0)? callSomething() : callSomethingElse() //this is NOT how it should be used

Die ternäre Anweisung ist dafür gedacht, je nach der ausgewerteten Bedingung einen von zwei Werten zurückzugeben. Dies ist besonders praktisch bei FP. Für Aufrufanweisungen, die keinen Wert zurückgeben, sollten Sie auf if-then-else zurückgreifen.