Thomas Kramer

IT-COW | .net-Framework

Webcast "Codequalität" (Teil 2) vom MSDN

By Administrator at April 28, 2010 18:57
Filed Under: .net-Framework, C#, Programmierung allgemein, Webcast-Reviews

Mittlerweile gibt es auch den zweiten Teil des MSDN-Webcasts zum Thema "Codequalität" zum Download. Mein Review zum ersten Teil ist hier verlinkt.

 

Die Dauer des zweiten Videos beträgt 1:22 Stunden gegenüber 50 Minuten des ersten Teils und hat auch deutlich mehr Substanz. Ich fasse an dieser Stelle einmal den Inhalt zusammen:

 

Als erstes empfiehlt Herr Roden, für ein neues Projekt im wesentlichen die Standardeinstellungen zu übernehmen, aber drei grundsätzliche Einstellungen immer abzuändern, im Projekteigenschaften-Tab unter dem Reiter Build/Erstellen:

 

  • Im Bereich "Errors and warnings/Fehler und Warnungen" den Warning level bzw. die Warnstufe auf den höchsten Level zu setzen, also Level 4. Damit gibt der Compiler soviele Warnungen aus wie möglich. Die Eigenschaft Suppress Warnings bzw. Warnungen unterdrücken auf Standardeinstellung belassen.
  • Im Bereich "Treat warnings as errors/Warnungen als Fehler behandeln" auf Alle einstellen, also -alle- Warnungen als Fehler behandeln. In größeren Projekten ist das aber unpraktikabel, möchte ich dazusagen - ansonsten kommt die Entwicklung zum Stehen. Das geht wirklich nur für private Projekte.
  • Und im Bereich "Output" sollte das XML documentation file bzw. die XML-Dokumentationsdatei aktiviert werden. Dann wird automatisch beim Kompilieren eine solche Datei erstellt - dafür sind Kommentare im Quellcode nötig, dazu weist der Compiler mit Warnungen darauf hin wenn bei einzelnen nicht-privaten-Methoden die einleitenden Kommentare fehlen.

Desweiteren wird empfohlen, für jede Klasse bzw. jeden Typ eine eigene Datei zu erstellen - selbst wenn die sehr klein sind. Partielle Klassen, also Klassen die sich auf mehrere Dateien verteilen, sind zu unterlassen und eigentlich nur für Codegeneratoren sinnvoll, um den generierten und den selbst erstellten Code voneinander zu trennen. Wenn ich es mir recht überlege, hätte ich diese bei meinen Arbeiten mit dem XSD-Codegenerator evtl. benutzen können... ansonsten erschweren Partielle Klassen die Suche, weil dann natürlich mehrere Dateien durchsucht werden müssen (aber man kann in Visual Studio immerhin auch direkt zur Codedefinition springen).

 

Namespaces sollten auf Ordner gemappt werden, also für jeden Namespace einen eigenen Ordner anlegen im Projektmappen-Explorer. Usings sollten alphabetisch sortiert werden und wenn bei Usings sich der erste Bezeichner ändert, sollte auch eine Leerzeile eingefügt werden. Die Sortierung muss nicht händisch erfolgen, sondern kann auch automatisch über das Kontextmenü und die Funktion "Organize Usings - Sort Usings" bzw. "Using-Direktiven organisieren - Using-Direktiven sortieren." bei den deutschen Visual Studio-Versionen erreicht werden. Die Leerzeilen zwischen den Blöcken müssen leider weiterhin händisch eingefügt werden.

 

Generell strittig ist die Vorgehensweise ob mit Leerzeichen oder Tabs eingerückt werden soll, Tabs sind einstellungsabhängig und je nachdem werden eine unterschiedliche Anzahl von Leerzeichen für ein einzelnes Tab benutzt. Bei neueren Visual Studio-Versionen werden beim Betätigen der Tab-Taste automatisch Leerzeichen eingefügt, das heißt echte Tabs gibt es bei Visual Studio im Editor eigentlich nicht mehr. 4 Leerzeichen sind die Standard-Einstellung in Visual Studio. Leerstellen bei Parametern von Methoden-Aufrufen/Deklarationen entfernt Visual Studio aber automatsch, außer die nach einem Komma.

 

Spätestens bei 100 Zeichen in einer Zeile sollte ein Zeilenumbruch erfolgen. Allgemein gilt, bei einem logischen Bruch sollte dies geschehen. Im Grunde macht man das schon automatisch ohne darüber nachzudenken, wenn man ein fortgeschrittener Programmierer ist. Es sollte nie mit mehr als einer Leerzeile getrennt werden zwischen den Blöcken. Mit Strg k und anschließendem Strg d kann die Autoformat-Funktion angewendet werden, die den Quellcode automatisch einrückt. Ergänzung von mir: man sollte auf jeden Fall mit eigenen #region-Blöcken arbeiten, damit man diese Blöcke zusammenklappen kann (Code-Folding).

 

Häufig wird in der Praxis bei Variablen-Zuweisungen, also Definitionen, eingerückt damit die =-Zeichen untereinander stehen. Jedoch ist das davon abhängig, ob im Visual Studio-Editor eine nicht-proportionale-Schrift eingestellt ist (was aber standardmäßig der Fall ist), worauf Herr Roden explizit hinweist. Eigentlich wird diese Voreinstellung jedoch praktisch nie verändert. Bei Visual Studio 2008 Express ist übrigens per default die Schrift Courier New eingestellt, bei dem Release Candidate von 2010 dagegen Consolas. Nicht-proportional-Schriften werden in der Combobox übrigens fett hervorgehoben. Herr Roden hat desweiteren daraufhin gewiesen, das häufig Deklarationen mit Definitionen verwechselt werden, Deklarationen sind z. b. string i und die Definition i=10, oder Deklaration mit Definition zusammen string i = 10. Desweiteren sollte für jede Variablendeklaration eine eigene Zeile benutzt werden und die Namen sollten sich auch nie allein durch Klein/Großbuchstaben unterscheiden, das ist auch sehr wichtig. Für lokale Variablen sollte daher gelten, das der Name mit einem _ beginnt (außerdem sollten diese Deklarationen am Anfang der Methode stehen), ansonsten sollte die Bezeichnungskonvention "Camel Case" verwendet werden - außer bei Properties, dort gilt "Pascal Case".

 

Es gibt verschiedene Benennungskonventionen: "Pascal Case" bedeutet, das jeder Wortbestandteil eines Wortes mit einem Großbuchstaben beginnt, ReadKey z. b. - "Camel Case" steht dagegen für dasselbe Prinzip, nur das der Anfangsbuchstabe klein bleibt (readKey), und bei "Uppercase" wird der ganze Name groß geschrieben (READKEY). Dementsprechend müsste es auch noch "Lowercase" geben, ist mir beim Betrachten des Videos dazu noch eingefallen. Außerdem sollten Variablen-Bezeichnungen keine Umlaute besitzen.

 

Allgemeines zur Benennung: Spezielle Präfixe sind allgemein zu vermeiden, außer I bei Interfaces (Ergänzung 02.05.2010: Exceptions sollten auf das Suffix -Exception enden). Keine Abkürzungen verwenden, außer Akronyme wie HTML. Desweiteren sollte im Team entschieden werden, ob man this. bei Abfragen voran setzt, für lokale Variablen - kann auch hilfreich für IntelliSense sein.

 

Kommentare sollten zumindest eine Leerstelle Abstand zum vorangegangenen Befehl haben. Für s/w-Drucker empfiehlt sich jedoch wegen der fehlenden farblichen Hervorhebung den Kommentar in eine eigene Zeile zu schieben. Block-Kommentare (/* */) können nicht verschachtelt werden und sollten daher eher nicht verwendet werden. Mit Strg k, Strg c kann man stattdessen besser automatisch mit // einrücken lassen (zuvor den Quellcode markieren). Strg k, Strg u gilt dagegen für uncomment, also auskommentieren rückgängig machen. Außerdem sollten Kommentare mit Verben beginnen und die Rechtschreibung sollte beachtet werden, besonders mit Blick auf die automatische XML-Dokumentation. Das die benutzte Sprache (deutsch oder englisch) für die Kommentare Team-weit festgelegt werden sollte, versteht sich von selbst.

 

Zugriffsmodifizierer sollten explizit gesetzt werden, das Standard-Template von Visual Studio ist da etwas ungeschickt und fügt keine Zugriffsmodifizierer automatisch ein. If-Anweisungen sollten immer mit { eingeleitet werden, auch wenn sie nur über zwei Zeilen gehen - wenn später eine weitere Anweisung hinzugefügt wird sieht man sonst möglicherweise nicht, das sich diese letzte Anweisung außerhalb des If-Blocks befindet und immer ausgeführt wird.

 

Das ist die komplette Zusammenfassung des zweiten Teils, mit Ergänzungen meinerseits. Insgesamt hat der zweite Teil deutlich mehr Substanz als der erste Teil, die Tastenkombinationen sollte ich mir besser einprägen.

 

Mein Review zum nächsten Teil ist mittlerweile endlich fertig.

 

Tag-Wolke

Monats-Liste