Einheitlicher Code - Coding conventions at its finest

Dieser Artikel wurde von Dietz, Felix am Sonntag, 8. September 2013 verfasst. Aktualisiert: 29.01.2014 23:05:01

Jeder Programmierer kennt das: Man hat seinen eigenen Stil. Dieser besteht zu Teilen aus gelernten Paradigmen und gesammelten Erfahrungen, aber auch aus Gewohnheit. Wenn man nun im Team arbeitet, ist es sehr wahrscheinlich, dass verschiedene Stile aufeinandertreffen. Jeder schreibt seinen Code in seinem Stil und es entstehen sogenannte Programmierergrenzen: Am Code wird erkannt, wer ihn geschrieben hat. Jemand, der sich einarbeitet, muss mit verschiedenen Stilen umgehen und diese im schlimmsten Fall unterschiedlich interpretieren können. Dieser Code-Flickenteppich ist ein Albtraum im Sinne der Wartbarkeit und Lesbarkeit.

Einheitlicher Code kann das verhindern: Durch die Vereinbarung einheitlicher Konventionen und eines einheitlichen Programmierstils verschwinden die Programmierergrenzen - jeder schreibt den Code gleich - und der Quelltext wird um ein Wesentliches lesbarer.

Was genau ist einheitlicher Code?

Einheitlicher Code entsteht, wenn vereinbarte Konventionen eingehalten und von jedem Programmierer im Team umgesetzt werden. Diese Konventionen können unter anderem einheitliche Namensgebung, Zeileneinrückung, Klammernsetzung, Zeilenumbruch, Dokumentation, aber auch die Verwendung von Compilerdirektiven und -Schaltern und die Vermeidung von Redundanz beinhalten.

Best Practices

Jede Programmiersprache hat ihre eigenen Paradigmen. Aus diesem Grund gibt es nicht einen globalen Satz "Best Practices". Für jeder Sprache werden unterschiedliche Konventionen gepflegt. Zudem haben SDKs ebenfalls unterschiedliche Konventionen. So pflegt Unity3D eine andere Namenskonvention als C#.

Wir werden uns im nachfolgenden Artikel mit den C# Konvention beschäftigen, die primär von Microsoft stammen. Die hier aufgelisteten Best Practices stellen bei Weitem keine komplette Liste dar. Es ist eine kleine Menge um auf den Geschmack zu kommen.

Coding Conventions am Beispiel C#

Klassen- und Methodennamen, Properties und sichtbare Fields werden in PascalCase notiert:

public class PerfectCustomer
{
    public int CustomerID{ get; set; }

    public string CustomerName;

    public void SummarizePurchases()
    {
    //...
    }

    public void CalculateExpenses()
    {
    //...
    }
}

Klassen in PascalCase Notation ist in vielen Sprachen gängig. In C# ist es zudem gängig, dass Methoden, Properties und alle sichtbaren Felder ebenfalls in PascalCase sind. Diese Schreibweise ist gut lesbar und zudem .NET-konform. Somit gibt es keinen Context-Switch zwischen eigenem Code und (Microsoft)-Bibliotheken.

In Unity3D werden Properties in Kleinschreibung benannt, z.B. rigidbody.

Klassennamen sind Substantive oder Substantivzusammensetzungen, Interfaces haben den Präfix I und sind Adjektive oder Substantive:

public class Protagonist
{
}

public class SandwichMaker
{
}

public class SoftwareProjectTeamMember
{
}

public interface ISpawnable
{
}

public interface IShape
{
}

public interface IAttachable
{
}

Ein Interface ist eine Fähigkeit, die eine Klasse unterstützt, daher sollte es auch ein Adjektiv oder alternativ ein Substantiv sein. Während eine Klasse - im Sinne des Substantiv - etwas ohne Bezug Existierendes ist (vgl. Wikipedia). Daher werden Klassen immer mit Substantiven benannt.

Das Präfix I macht sofort erkennbar, dass es sich um ein Interface handelt. Der Zweck wird vorallem deutlich, wenn man Interfaces mit Substantive benennen muss.

Methodenargumente und lokale Variablen werden in camelCase notiert, pro Zeile nur eine Anweisung:

public class UserLog
{
    public void Add(LogEvent logEvent)
    {
        int itemCount = logEvent.Items.Count;
        ++itemCount;
        DoStuff(itemCount);
        // ...
    }
}

camelCase suggeriert sofort, das es sich um lokale Variablen handelt.

Bei verschachtelte Anweisungen ist die Chance höher, dass sich Fehler einschleichen, weil der Entwickler zum Beispiel das negieren vergessen hatte oder die Prioritäten der Operatoren verwechselt hat.

Zudem erhöht es in vielen Fällen die Lesbarkeit.

Namespaces haben eine durchschaubare Struktur und bilden die Ordnerstruktur ab:

namespace Game.Assets.Scripts.Player
namespace Product.Module.Component
namespace System.Math

Durch die strenge Einhaltung dieser Regel lassen sich Klassen schnelle wiederfinden. Zudem forciert es eine feste Anordnung der Quelldateien, was die Wartbarkeit des Projekt erhöht.

Zusammengehörige Klammern werden in gleicher Indention geschrieben und jede Klammer bekommt eine eigene Zeile:

class Program
{
    static void Main(string[] args)
    {
    }
}

Erhöht die Lesbarkeit und macht sehr schnell Anfang und Ende eines Codeblocks erkennbar.

If-Klauseln werden immer geklammert:

if ((val1 > val2) && (val1 > val3))
{
    // Take appropriate action.
}

Auch bei nur einem Befehl, sollen geschweifte Klammern bei If-Klauseln genutzt werden. Das verhindert unter anderem neue Fehler, beim Bugfixing. So fügt beispielsweise ein Entwickler eine weitere Anweisung zum Code vor der eigentlichen Anweisung und übersieht dabei, dass die Zeile danach nicht mehr zum if mitgehört.

Weiterführende Literaturen

 
blog comments powered by Disqus

Google Anzeigen

Neusten Blogeinträgen

  • CSS: Animationen

    CSS3 bietet von Haus aus Möglichkeiten zur Definition von Animationen über die Property animation. Wie es funktioniert zeigen wir in diesem Artikel.

  • CSS: Alternierende Tabellenzeilen

    Um die Lesbarkeit von Tabellen zu steigern, bietet die CSS die Möglichkeit Tabellenzeilen alternierend zu färben. Wie das funktioniert zeigen, wir ...

  • Unity3D: Konsolenausgabe formatieren

    Die Unitykonsole ist einer der meistgenutzten Feature wenn es bei Unity um Fehlersuche und -behandlung geht. Sie wird dabei schnell voll und verli ...

  • Unity3D: Singleton für langsame Operationen

    Operationen wie Object.FindObjectOfType werden in der Dokumentation von Unity3D Entwickler selbst als sehr langsam beschrieben. Aus dem Grund wird ...

  • Unity3D: Optionale Parameter

    Unity3D (4.3.1) unterstützt keine optionale Parameter, wenn die betroffene Skriptdatei in einem Namespace definiert wird.

Popular Threads

Share it on your network