Sauberer Code in C#: So schreiben Sie, dass Sie es Ihren Kollegen zeigen können

Einleitung: Warum sauberer Code nicht nur Ästhetik, sondern auch Geld ist

Stellen Sie sich vor, Sie fangen einen neuen Job an, öffnen ein C#-Projekt und sehen eine Methode mit 500 Zeilen, Variablen wie a, b, temp und Kommentare in einer Mischung aus Russisch und Englisch. Kommt Ihnen bekannt vor? Wahrscheinlich ja. Solcher Code funktioniert zwar, aber seine Wartung wird zur Hölle. Sauberer Code in C# ist keine Marotte von Perfektionisten, sondern ein Werkzeug, das Stunden, Nerven und Geld des Teams spart.

In diesem Artikel halten wir keine Moralpredigten. Stattdessen betrachten wir konkrete Techniken, die Ihnen helfen, in C# so zu schreiben, dass der Code für Anfänger verständlich ist und erfahrene Entwickler erfreut. Los geht's!

1. Namen sind wichtig: Wie man Variablen, Methoden und Klassen benennt

Der einfachste Weg, Code sauberer zu machen, ist die Verwendung aussagekräftiger Namen. C# ist streng bei der Groß-/Kleinschreibung, aber das ist keine Ausrede für int x oder string d.

Variablen: Sagen Sie, was Sie speichern

Schlecht:

int d; // Was ist das? Datum? Distanz? Geld?string n; // Name? Nummer? Notebook?

Gut:

int daysUntilDeadline;string userName;

Die Regel ist einfach: Wenn Sie in einem Monat ohne Kommentar nicht verstehen, was eine Variable speichert, ist der Name schlecht. Vermeiden Sie Abkürzungen wie usr oder cnt – sie sparen Sekunden beim Tippen, kosten aber Minuten beim Lesen.

Methoden: Verb + Substantiv

Eine Methode ist eine Aktion. Benennen Sie sie so, dass klar ist, was sie tut:

• CalculateTotalPrice() – berechnet den Gesamtpreis;
• SendEmailNotification() – sendet eine Benachrichtigung;
• ValidateUserInput() – überprüft die Benutzereingabe.

Schlechtes Beispiel: ProcessData() – zu abstrakt. Was bedeutet "verarbeiten"? Löschen? Umwandeln? Speichern?

Klassen: Substantive im Singular oder Plural

Eine Klasse ist eine Entität. User, Order, PaymentProcessor. Vermeiden Sie Suffixe wie Manager oder Helper, wenn sie architektonisch nicht gerechtfertigt sind. Oft werden solche Klassen zu "Müllhalden" für alles Mögliche.

2. Methoden sollten klein sein und eine Sache tun

Die goldene Regel für sauberen Code: Eine Methode sollte eine Aufgabe lösen und diese gut lösen. Wenn eine Methode mehr als 20–30 Zeilen umfasst, sollte sie wahrscheinlich aufgeteilt werden.

Beispiel: Refactoring eines Monsters

Stellen Sie sich eine Methode vor, die einen Benutzer registriert:

public void RegisterUser(string name, string email){    // Validierung    if (string.IsNullOrWhiteSpace(name)) throw new ArgumentException();    if (!email.Contains("@")) throw new ArgumentException();    // Speichern in der DB    using var db = new AppDbContext();    var user = new User { Name = name, Email = email };    db.Users.Add(user);    db.SaveChanges();    // E-Mail senden    var smtp = new SmtpClient();    smtp.Send("admin@site.com", email, "Welcome", "Hello!");}

Was ist hier falsch? Drei Verantwortlichkeiten: Validierung, Datenbankarbeit, E-Mail-Versand. Wenn sich die Versandlogik ändert, muss die Registrierungsmethode angepasst werden. Teilen wir auf:

public void RegisterUser(string name, string email){    ValidateUser(name, email);    var user = CreateUser(name, email);    SaveUser(user);    SendWelcomeEmail(email);}

private void ValidateUser(string name, string email){    if (string.IsNullOrWhiteSpace(name))         throw new ArgumentException("Name is required", nameof(name));    if (!email.Contains("@"))         throw new ArgumentException("Invalid email", nameof(email));}

private User CreateUser(string name, string email){    return new User { Name = name, Email = email };}

private void SaveUser(User user){    using var db = new AppDbContext();    db.Users.Add(user);    db.SaveCh