Coding Styles - Versionsgeschichte

Manuel: Fett ist anders als in Markdown...

2018-02-28T17:05:46Z

Fett ist anders als in Markdown...

Manuel: Coding styles nach PR #245 überarbeitet

2018-02-28T17:02:03Z

Coding styles nach PR #245 überarbeitet

Manuel: Die Seite wurde neu angelegt: „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 folg…“

2018-01-11T20:44:11Z

Die Seite wurde neu angelegt: „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 folg…“

Neue Seite

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:

<source lang="csharp">
// So soll es sein
string DoSomething()
=> "test";

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

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

<source lang="csharp">
public string Oeffentlich { get; set; }
// Hier könnten wir den Modifizierer weglassen, tun es aber nicht:
private string Privat { get; set; }
</source>

== Properties ==
* In der Codedatei über dem Konstruktor anordnen.
* public <type> <name> => bla; (neue C#-Syntax bei Properties mit nur get):

<source lang="csharp">
// So soll es sein
public int X => x;

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

== Private Felder ==
Private Felder erhalten kein Namenspräfix (oft z.B. "_")

<source lang="csharp">
// So soll es sein
private int x;

// So nicht
private int _x;
</source>

= In Methoden =

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

<source lang="csharp">
// 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;
}
}
</source>

== Lokale Variablen ==
Bei lokalen Variablen verwenden wir nur <code>var</code>, wenn der Typ klar erkennbar ist (z.B. bei Instanzierungen):
<source lang="csharp">
// 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
</source>

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

<source lang="csharp">
// So soll es sein
using (var stream = ...)
using (var reader = new StreamReader(stream))
{
}

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

== 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) ==
Wenn die Klammern weggelassen werden können, folgt z.B. die Folge auf ein <code>if</code> in der nächsten Zeile:

<source lang="csharp">
// So soll es sein
if (true)
DoSomething();

// So nicht
if (true) DoSomething();
</source>

== out-Variablen aus if-Statements ==
<code>out</code>-Variablen nur innerhalb des <code>if</code>s bzw. der Folge verwenden:

<source lang="csharp">
// 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!
</source>

== Linq ==
Mit Methodenaufrufen. Die LINQ-Keywords werden mehrheitlich abgelehnt.

<source lang="csharp">
// 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;
</source>

@@ Zeile 123: / Zeile 123: @@
 </source>
-== Blöcke (z.B. bei if oder switch) ==
+== 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) ==
+== 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 <code>if</code> in der nächsten Zeile:
@@ Zeile 138: / Zeile 138: @@
 </source>
-**Switch-Konstruktionen sind gleich zu behandeln**
+'''Switch-Konstruktionen sind gleich zu behandeln'''
 == out-Variablen aus if-Statements / "is" in if ==
@@ Zeile 154: / Zeile 154: @@
 </source>
-**Das gleiche gilt auch für die Verwendung der neunen C#-is-Syntax!**
+'''Das gleiche gilt auch für die Verwendung der neunen C#-is-Syntax!'''
 == Linq ==

@@ Zeile 35: / Zeile 35: @@
 == Properties ==
 * In der Codedatei über dem Konstruktor anordnen.
 * public <type> <name> => bla; (neue C#-Syntax bei Properties mit nur get):
@@ Zeile 52: / Zeile 53: @@
 == Private Felder ==
-Private Felder erhalten kein Namenspräfix (oft z.B. "_")
+Private Felder erhalten kein Namenspräfix (oft z.B. "_") und die Namen sollten mit einem Kleinbuchstaben beginnen.
 <source lang="csharp">
@@ Zeile 122: / Zeile 123: @@
 </source>
-== Blöcke (z.B. bei if) ==
+== Blöcke (z.B. bei if oder switch) ==
 Bei der Umfrage ist kein eindeutiges Ergebnis bezüglich der Frage herausgekommen. Jeder so wie er will.
@@ Zeile 137: / Zeile 138: @@
 </source>
-== out-Variablen aus if-Statements ==
+**Switch-Konstruktionen sind gleich zu behandeln**
 <code>out</code>-Variablen nur innerhalb des <code>if</code>s bzw. der Folge verwenden:
@@ Zeile 150: / Zeile 153: @@
 DoSomething(val); // Hier sind wir wieder außerhalb des ifs!
 </source>
 == Linq ==