Für einen Entwickler ist es im Alltag immer wichtig einen gut lesbaren und möglichst intuitiven Code zu schreiben. D.h. andere Entwickler sollten schnell verstehen können worum es geht und was welche Methode macht und das ggf. sogar ohne Dokumentation ( auch wenn diese natürlich unverzichtbar ist ). Optimal ist dies der Fall, wenn ein Methodenname so eindeutig ist, dass jeder weiß was sie macht.

Auf folgende Dinge sollten geachtet werden :

• Benutze keine Unterstriche oder ähnliche, nicht alphanumerische, Zeichen
• Benutze möglichst keine Wörter, welche in der Programmiersprache eingebettet sind
• Versuche einfach zu lesende Namen zu verwenden
• Verwende PascalCasing für Namespaces, Klassen, Typen und Methoden sowie Properties
• Verwende camelCasing für Parameter in Methoden und für lokale variablen

DON’T !

public myClass
{
    public void method( myclassname valuename )
    {
        //logik
    }
}

DO !

public MyClass
{
    public void Method( MyClassName valueName )
    {
        //logik
    }
}

In diesem zweiten Beitrag zum Thema “Do’s and Don’ts” möchte ich ein Szenario ansprechen, welches mich erst vor kurzem in meinem ArmyGen Projekt beschäftigt hat. Es geht um das “Klonen” von Objekten. Das .NET Framework bietet nur ein Interface, welches sich “IConeable” nennt, an um das Klonen von Objekten einzubinden. Unglücklicherweise besagt die einzige Methode in diesem Interface (“Clone()“) nicht um welche Art des Klonens es sich dabei handelt.

Man unterscheidet nämlich zwischen dem “DeepClone” und dem “ShallowClone”. Beim Deepclone soll eine Kopie des Objektes entstehen und hinzu sollen alle referenzierten Objekte in diesem Objekt ebenfalls rekursiv kopiert werden. Beim ShallowClone hingegen soll lediglich ein Teil des Objektes kopiert werden und der Rest sollen vorhandene Referenzen sein. Also :

DON’T !

public MyClass : ICloneable
{
    public void Clone()
    {
        //logik
    }
}

Read the rest of this entry »

Unter dieser neuen Kategorie möchte ich in Zukunft regelmäßig einige Fragen aufzeigen die im Alltag eines Programmierers, oder zumindest bei mir, öfters auftauchen. Es geht um Kontrukte, bei denen man sich manchmal nicht sicher ist wie es nun in der Praxis “richtig” geschrieben wird. Ich habe mich im letzten halben Jahr sehr oft gefragt welche schreibweise verschiedener Konstrukte wohl am üblichsten ist, was am besten lesbar ist, welches Naming wohl am verständlichsten ist, oder sogar welche Konstrukte möglicherweise Fehleranfällig sind.

In diesem ersten Beitrag zum Thema “Do’s and Don’ts” möchte ich direkt auf ein Szenario stoßen, welches ich gestern in dem Blog von Coding Horror gefunden habe. Es geht um die weitverbreitete Implementierung der CompareTo() Methode (wichtig z.B. bei Sortierungen). Einige Leute wollen besonders viel aus ihrer Optimierung herausholen und versuchen beispielsweise folgenden Ansatz …

DON’T !

public int CompareTo( int valueA, int valueB )
{
    return valueA - valueB
}

Auf den ersten Blick macht das ganze vielleicht Sinn, denn sollten beide wirklich gleich groß sein wird 0 zurückgegeben und ansonsten halt ein Wert der entweder >0 oder <0 ist. Gar nicht mal so schlecht denn man spart sich ein paar If Konstrukte innerhalb der Methode. Stellt euch jedoch einmal vor man würde die Methode folgendermaßen aufrufen :

Read the rest of this entry »