Coding Styles

In einer der ersten Streams im Jahr 2018 und damit der dritten Staffel kam die Idee im Stream, eine einheitliche Basis der Coding-Styles einzuführen. Der folgende Artikel ist aus einer Umfrage her entstanden und ist keine harte Regelung, sondern nur eine Richtlinie.

Allgemeines

Leerzeilen

• Vor returns
• Vor ifs

In Klassen

Methoden mit einer Zeile

Bei einzeiligen Methoden verwenden wir den neuen C#6-Pfeiloperator:

// So soll es sein
string DoSomething()
	=> "test";

// So nicht
string DoSomething()
{
	return "test";
}

Sichtbarkeit (private, public etc...)

Wir verwenden vor allen Elementen die Sichtbarkeitsmodifikatoren, auch wenn man sie als Standardwert (private) weglassen könnten:

public string Oeffentlich { get; set; }
// Hier könnten wir den Modifizierer weglassen, tun es aber nicht:
private string Privat { get; set; }

Properties

• In der Codedatei über dem Konstruktor anordnen.
• Die Namen der Properties, wenn diese public sind, großschreiben.
• public <type> <name> => bla; (neue C#-Syntax bei Properties mit nur get):

// So soll es sein
public int X => x;

// So nicht
public int X
{
	get
	{
		return x;
	}
}

Private Felder

Private Felder erhalten kein Namenspräfix (oft z.B. "_") und die Namen sollten mit einem Kleinbuchstaben beginnen.

// So soll es sein
private int x;

// So nicht
private int _x;

In Methoden

this

this nur dann verwenden, wenn es nicht anders geht (bei gleichen Namen von Parameter und Feldern):

// So soll es sein
class Test
{
	private int x;
	public Test(int x)
	{
		this.x = x;
	}
}

// So nicht
class Test
{
	private int x;
	public Test(int y)
	{
		this.x = y;
	}
}

Lokale Variablen

Bei lokalen Variablen verwenden wir nur var, wenn der Typ klar erkennbar ist (z.B. bei Instanzierungen):

// So soll es sein
var x = new X();
var x = GetX();
Y y = ComplicatedMethod(); // Hier nicht erkennbar

// So nicht
X x = new X();
X x = GetX();
var y = ComplicatedMethod(); // Hier nicht erkennbar

Mehrere usings

Alle usings innerhalb von Methoden (nicht die am Anfang der Datei) werden nicht in Klammern verschachtelt und untereinander geschrieben:

// So soll es sein
using (var stream = ...)
using (var reader = new StreamReader(stream))
{
}

// So nicht
using (var stream = ...)
{
	using (var reader = new StreamReader(stream))
	{
	}
}

Blöcke (z.B. bei if)

Bei der Umfrage ist kein eindeutiges Ergebnis bezüglich der Frage herausgekommen. Jeder so wie er will.

Bei Blöcken ohne Klammern (z.B. if mit nur einer Zeile oder switch)

Wenn die Klammern weggelassen werden können, folgt z.B. die Folge auf ein if in der nächsten Zeile:

// So soll es sein
if (true)
	DoSomething();

// So nicht
if (true) DoSomething();

Switch-Konstruktionen sind gleich zu behandeln

out-Variablen aus if-Statements / "is" in if

out-Variablen nur innerhalb des ifs bzw. der Folge verwenden:

// So soll es sein
if (int.TryParse("3", out int val))
	DoSomething(val);

// So nicht
if (int.TryParse("3", out int val))
	DoSomething(val);
DoSomething(val); // Hier sind wir wieder außerhalb des ifs!

Das gleiche gilt auch für die Verwendung der neunen C#-is-Syntax!

Linq

Mit Methodenaufrufen. Die LINQ-Keywords werden mehrheitlich abgelehnt.

// So soll es sein
var query = numbers.Where(num => num % 2 == 0).OrderBy(n => n);

// So nicht
var query = 
	from num in numbers
	where num % 2 == 0
	orderby num
	select num;