Boas Enkler BE IT-Solutions B&R DV InfoSys. GmbH Code Design Guidelines in der Praxis
Boas Peter Enkler Teamlead / Solutionsarchitect 10 Jahre Software Entwicklung Teamorganisation Enterprise Applications Code Qualität / CCD www.be-it.net
Über diese Session Sensibilisierung Richtlinien How To Do s, Consider, Dont s Code Beispiele
Fallbeispiel Vorher Fehler beim Kunden Unspezifische Fehler Data Races Undurchschaubares Verhalten Lange Einarbeitungszeit Unmut Nachher Fehler nur in der Testphase Klare Fehlermeldungen Studenten für Outsourcing Klare Verantwortlichkeiten
Was macht dieser Code? aus CodeKicker.de
Code Richtlinien Komprimierte Erfahrungswerte Werkzeug für Code Qualität Wartbarkeit Robustheit API Usability Bessere Lesbarkeit Standards Sichere Freiräume für Entwickler
Faktoren Anforderungen / Szenarien Team Code Richtlinien Technische Umgebung Standards
Einschränkungen Keine Allgemeingültigkeit Sie alleine machen keine Qualität Keine Garantie für eine funktionierende Software (keine Aussage über Domainlogik) Sie machen kein funktionierendes Team
Vorgehen Richtlinien erstellen Iterativ Kommunikation mit den Teammitgliedern Vorbehalte ausräumen YAGNI (Nur das was Sie brauchen) Übersichtsblatt Diskussionsforum
Wer definiert Richtlinien? Konkrete Rolle Anerkannter Entscheidungsträger Verantwortung Hilfe bei Fragen Fortlaufende Aktualisierung der Standards Vermittelt bei Konflikten Entscheidet bei Ausnahmen / Lücken
Es gibt Sie (!) Ausnahmen Nur bei gewichtigen Gründen (Security, ) Dokumentieren der Ausnahmen Anlass für Review der Richtlinien Temporäre Workarounds müssen terminiert werden
Ausnahmen im.net FX
Demo DataProvider Projektstruktur und Einstellungen
Projekt Settings Treat Warning as Errors Warning Level 4 Generate Xml Output Client Framework Code Contracts API Validation Static Code Analysis
Strukturelle Aufbau Namespace Ordner Korrelation Jeder Typ in eigene Dateien Datei passend zum Typ benennen Interface Assembly Komponentenorientiert Shared Build Output (bin folder) <Company>.<Component>.dll <Company>.<Component>.Interface.dll <Company>.<Component>.Tests.dll <Company>.<Area>.Common.dll
Demo DataProvider Implementierungsregeln
Definitionen Pascal Case Camel Case Ungarische Notation * UpperCamelCase {Bezeichner} Jedes Wort beginnt mit Großbuchstaben LowerCamelCase {bezeichner} Worte in einem Wort beginnen mit einem Großbuchstaben {Präfix} {Datentyp} {Bezeichner} uint MyValue uint myvalue uint uimyvalue * Die Ungarische Notation sollte in einer.net Umgebung nicht angewendet werden
Felder Private interne Daten Konstanten Statische ReadOnly immutable Werte Keine Public oder Proteced Felder Keine binärkompatible Änderung zu einem Property möglich
Properties Wrapper auf Felder Werte / Zustände von Entitäten Vorsicht vor DataRaces Nicht zum Austausch von Werten zwischen Methoden
Kommentare Nur Notwendiges Kommentieren In der sicheren Sprache API Dokumentation Parameter semantisch Beschreiben Keine Syntax erklären Kein Methoden Ersatz Kein Changelog
Datum Timespan DateTime DateTimeOffset Keine Datumsangabe Zeitangaben Öffnungszeiten 10:00-13:00.NET < 3.5 >=.NET 3.5 Reine Datumswerte Geburtstage 00:00:00 Zeitkomponente Wenn Zeitzonen keine Rolle spielen Silvester 31.12. 23:59 Genauer Zeitpunkt Termine Online Meeting 13:00 GMT+1
Demo DataProvider Klassen und Member Design
Object.ToString() Object.ToString() überschreiben Debugger Anzeige Kurze Texte Lesbare Texte DebuggerDisplay Attribute IFormatable Overload Nur trivial Code ohne Seiteneffekte Keine Exceptions im ToString() werfen
Object.Equals() x.equals(y) == y.equals(x) x.equals(x) == true y.equals(null) = false Keine Exceptions werfen Keine Wertgleichheit bei veränderbaren Werten Value Type Erweiterungen Equals immer überschreiben (Standard = Reflection) IEquatable<T> (Boxing vermeiden)
Object.GetHashCode() Wenn Equals() überschrieben => immer GetHashCode() überschreiben Equal Objekte => Gleicher Hashcode x.equals(y) => x.gethashcode() == y.gethashcode() Keine Änderung des Hashcodes zur Object Lifetime Keine Exceptions in GetHashCode() werfen
Parameter Designfehler im.net FX
Parameter II Reihenfolge und Benennung bei Überladung beibehalten Basistypen als Parameter Konkrete Typen als Rückgabewerte Out und Ref Parameter vermeiden Out Parameter ans Ende
Beispiel Exception Nichtssagende Fehlermeldung Aussagekräftige Fehlermeldung
Exception Ableitung System.Exception Stacktraces erhalten Tester Doer Pattern TryDo Pattern Keine ReturnCodes Nicht System.Exception abfangen Niemals System.Exception werfen Nicht von ApplicationException ableiten
Quellen Buch Framework Design Guidelines http://stylecop.codeplex.com/ MSDN Writing Quality Code MSDN Design Guidelines for Developing Class Libraries IDesign GuideLines http://www.clean-code-developer.de/ Mein BLog -> BE-IT.NET