Schlagwort: naming

Englisch, Deutsch oder Denglisch?

Der Kunde zahlt fürs Code-Schreiben und nicht fürs Code-Lesen!

In einer Firma, wo alle Software-Entwickler und IT’ler Deutschsprachige waren, hat der Inhaber & CEO uns befohlen alle Kommentare (nur Kommentare) auf Deutsch zu schreiben. Ein Jahr später, nachdem das Projekt im Verzug war und die Entwicklung des Software-Systems nicht schnell genug vorangegangen war, wurden drei neue Software-Entwickler aus Spanien eingestellt. Die neuen Kollegen waren alle sehr gute Software-Entwickler und beherrschten souverän ihr Fach, jedoch verstanden kein Wort Deutsch. Danach wurden noch mindestens fünf weitere Software-Entwickler, ebenfalls aus Spanien, eingestellt…
Nun hatten wir alle Hände voll zu tun. Wir drei Deutschsprachigen müssten alle Kommentare nun auf Englisch übersetzen und ersetzen, anstatt unsere Aufgaben nachzugehen.

In eine andere Firma, hatte ich das „Vergnügen“ Code auf Denglisch zu lesen. Manche Namen waren Deutsch, manche waren Englisch, und der Rest eine beliebige Mischung aus Deutsch und Englisch. Dass alle Programm-Elemente (Interfaces, Klassen, Delegates, Events, Methoden, Properties etc.) in Microsoft .NET Frameworks auf US-Englisch waren, ist natürlich trivial…

Das Lesen der Code war extrem schwierig und eine Herausforderung an/für sich. Beispiel für Variable-Namen:
messValue, measWert, measValue, messWert (diese Namen standen für: measured value, bzw. gemessener Wert).
Auch wenn man alle Namen auf Deutsch schreibt, die Hälfte von Code ist und bleibt auf Englisch, da die Schlüsselwörter und alles Andere in MS .NET Frameworks in US-Englisch ist, wie: string.IsNullOrEmpty(…), PropertyChanged, File.Exist(…), using(var x = new MemoryStream(…)), usw. usf.

Deswegen behaupte ich: Es kann kein Code auf „Deutsch“ geschrieben werden, wenn man das versucht, dann entsteht immer ein Code auf „Denglisch“. Man stelle sich nur vor, jemand würde Denglisch schreiben oder reden:
„I war very froh to sehen you nochmal“.

Ich verwende gerne US englische Namen (Color statt Colour, Synchronize statt Synchronise, usw.). Somit bleibt alles einheitlich, unmissverständlich, eindeutig, klar und der Lese-Fluss bleibt sehr flüssig.

Denglisch kostet mehr Zeit, mehr Zeit zum Lesen und mehr Zeit zum Verstehen.
Je öfter der Code von je mehr Kollegen (wieder)gelesen wird, desto mehr Zeit wird verschwendet!
Zeit ist Geld. Somit verursacht Code auf Denglisch unnötige zusätzliche Kosten.

Der Kunde zahlt fürs Code-Schreiben und nicht fürs Code-Lesen!

Naming System & Code lesen

Der Kunde zahlt fürs Code-Schreiben und nicht fürs Code-Lesen!

Um Code schneller lesen und durchsuchen zu können, habe ich im Laufe der Zeit, mein System für die Benennung einige Programmelemente verfeinert:

  • Interfaces beginnen mit „I„, wie: IAuthor, IBook, IPublisher,…

  • Abstrakte Klassen beginnen mit „A„, wie: AAuthor, ABook, APublisher,…

  • Enums beginnen (bei mir) mit „E„, wie: „EOperationMode“, „EError“, „EDeviceType“, „EPeriodKind“,…

  • Helper-Klassen enden mit „Helper„, wie: „FileHelper“, „CommandHelper“, „SecurityHelper“,…

  • Model-Klassen (MVC, MVVM) enden mit „Model„, wie: ServiceModel, MachineModel, ConfigModel, ProductModel, CategoryModel,…

  • DTO-Klassen enden mit „DTO„, wie: PersonDTO, ProductDTO,…

  • POCO-Klassen enden mit „POCO„, wie: PersonPOCO, ProductPOCO,…

  • Delegates enden mit „Handler„, wie: CommandInvokedHandler, ValueChangedHandler, SafeModeActivationChangedHandler, StreamOpeningHandler, StreamOpenedHandler, StreamClosingHandler, StreamClosedHandler, UserLoggedInHandler, UserLoggedOutHandler,…

  • Event-Handling-Methoden beginnen mit „On“ plus Event-Name, und können -wenn passend- mit „ed“ enden, also: „On<EventName>ed„, wie: OnCommandInvoked, OnValueChanged, OnSafeModeActivationChanged, OnStreamOpening, OnStreamOpened, OnStreamClosing, OnStreamClosed, OnUserLoggedIn, OnUserLoggedOut, OnMachineReplaced, OnErrorOccured,…

  • Funktionen/Methode, die etwas Berechnen und eine Zahl zurückgeben beginnen mit „Calc“ oder „Calculate“ (und NIEMALS mit „Get“!), wie: CalculateCircleSurface(…), CalculateStandardDeviation(…) oder kurz: CalcStdDeviation(…)

  • Methoden die asynchron laufen enden mit „Async“, wie: CalcStdDeviationAsync(IEnumerable pTooManyNumbers),…

  • Boolsche Properties beginnen mit „Is„, „Has„, „Use„, „Contains“ udg., wie: „IsEnabled“, „IsReady“, „IsEmpty“, „HasElement“, „ContainsError“, „ContainsNull“, „UseForceMode“, „DoBackup“,…

  • Properties die Exception werfen können, werden NICHT als Properties, sondern mit „Get…()“ und „Set…()“ implementiert (so wie es die C# Sprach-Designer Anders Hejlsberg, Bill Wagner & Co vorgesehen haben), denn ein Property sollte niemals Exceptions werfen, schon gar nicht der Getter. Ausgenommen sind die Indexer (wegen IndexOutOfRangeException).

  • „Get…“ Methoden welche Exceptions abfangen und behandeln enden mit:
    • „OrNull“ wenn bei Exception NULL zurückgeliefert wird
    • „OrDefault“ wenn bei Exception Default-Wert (z. B. default(int)) zurückgeliefert wird

  • Member-Variablen beginnen mit „m“ oder „m_„, wie: mFirstName oder m_FirstName

  • Parameter beginnen mit „p“ wie: CalcRectSurface(int pWidth, int pHeight), SetTopLeft(int pX, int pY),…

  • Konstanten werden GROSS_GESCHRIEBEN: DEFAULT_VALUE, MAX_VALUE,…

Der Beispiel-Code unten erfüllt die oben erwähnten Regeln.
Versuche herauszufinden: Welcher Name ist ein Property, welcher ein Parameter, welcher eine Member-Variable und welcher eine Konstante:

Konstanten, Parameter, Properties etc. sind eindeutig zu erkennen