Mittendrin.

Zurück

Flurfunk der eXperts.

Hier erfahren Sie mehr über eXperts, Technologien und das wahre Leben in der SDX.

LINQ Coding Guidelines #3–Einrückungen und Umbrüche

02.12.201408:00 Uhr , Alexander Jung

Eigentlich DAS Standardthema, wenn’s um Coding Guidelines geht: Wo breche ich Zeilen um und wie rücke ich ein?

Empfehlung:
* LINQ-Ausdrücke sollten konsequent und einheitlich umgebrochen werden.
* Unterausdrücke sollten einheitlich eingerückt werden.
* Die Einrückungstiefe sollte dem Standard im restlichen Code entsprechen.

 

Man sollte meinen, dass sich das Thema nach jahrzehntelanger Grundsatzdiskussion und automatischer Code-Formatierung in modernen IDEs von selbst erledigt hätte. Aber weit gefehlt.

Als extremes Beispiel der Anfang des RayTracers:

image

Einrückungstiefen von 1, 4, 5, 7 und noch mehr Zeichen. Umbrüche in einzelnen Unterausdrücken und Funktionsaufrufen. Und der Rest der Methode wird nicht besser.

Ebenso ein typischer Vertreter:

   1: public ApiExpert Get(int id)

   2: {

   3:     return this.db.eXperts

   4:         .Where(x => x.Id == id)

   5:         .ToArray()

   6:         .Select(x => new ApiExpert

   7:                         {

   8:                             Id = x.Id,

   9:                             IsAdmin = x.IsAdmin,

  10:                             Name = x.Name,

  11:                             CustomerResponse = x.CustomerStatements

  12:                                                     .Select(c =>

  13:                                                         new KeyValuePair<string, string>(

  14:                                                             c.Id.ToString(CultureInfo.InvariantCulture),

  15:                                                             c.Statement))

  16:                         })

  17:         .FirstOrDefault();

  18: }

Willkürliche Einrückungen. Umbrüche, die sich nicht an der Logik der Abfrage orientieren. Man hat den Eindruck, der Quelltext flüchtet zum rechten Bildschirmrand.

 

Die gleiche Methode wird gleich besser lesbar…

   1: public ApiExpert Get(int id)

   2: {

   3:     return this.db.eXperts

   4:         .Where(x => x.Id == id)

   5:         .ToArray()  

   6:         .Select(x => new ApiExpert

   7:         {

   8:             Id = x.Id,

   9:             IsAdmin = x.IsAdmin,

  10:             Name = x.Name,

  11:             CustomerResponse = x.CustomerStatements.Select(c =>

  12:                 new KeyValuePair<string, string>(c.Id.ToString(CultureInfo.InvariantCulture), c.Statement)

  13:                 )

  14:         })

  15:         .FirstOrDefault();

  16: }

… wenn sich die Einrückungstiefe am Standard (4 Zeichen) orientiert, und wenn man beim Unterausdruck auf Umbrüche verzichtet.

 

Ein weiteres Beispiel aus der Praxis:

   1: IQueryable<AllocationTimeSpan> allTimeSpans = _context.AllocationSet.OfType<Allocation>().Select(a => new AllocationTimeSpan

   2: {

   3:     From = a.AllocatedFrom,

   4:     To = a.AllocatedTo,

   5:     Status = (Status)(a.Status),

   6: }).Distinct().OrderBy(ts => ts.From);

Durch die Umbrüche dominiert das Mapping der Daten anstatt der Abfragelogik. Bricht man hingegen an den einzelnen Operationen um, wird die Logik gleich deutlicher, die Kette der Aufrufe offensichtlich:

   1: IQueryable<AllocationTimeSpan> allTimeSpans = _context

   2:     .AllocationSet

   3:     .OfType<Allocation>()

   4:     .Select(a => new AllocationTimeSpan

   5:     {

   6:         From = a.AllocatedFrom,

   7:         To = a.AllocatedTo,

   8:         Status = (Status)(a.Status),

   9:         AvailableMDRatio = a.AvailableMDRatio

  10:     })

  11:     .Distinct()

  12:     .OrderBy(ts => ts.From);

 

Leider unterstützt einen die Code-Formatierung im Visual Studio bei der Formatierung von LINQ-Ausdrücken nicht immer so ganz ideal. Aber wenn man sich an ein oder zwei Eigenheiten gewöhnt hat (z.B. den Lambda-Ausdruck in einem Select in der gleichen Zeile zu beginnen, statt in die nächste Zeile zu rücken), dann kann man auch damit gut lesbaren Code produzieren – wenn man das will.

Tags: .NET Dev LINQ

1 Kommentar

02.12.20148:12 Uhr
Matthias

Wichtig aus meiner Sicht ist dabei auch immer: Gehirn einschalten! Visual Studio und auch ReSharper formatieren da recht wild und lassen den Code nach rechts "kippen". Auch die StyleCop-Empfehlungen sind nicht besser. Leider verlassen sich meiner Ansicht nach immernoch zu viele Entwickler blind auf diese Tools und dann kommen solche Code-Fundstücke raus, wie du sie hier gezeigt hast.

Viele Grüße,
Matthias

Dein Kommentar wartet auf Freischaltung.

Artikel kommentieren

Zurück

Tag Cloud


Kontakt aufnehmen


Anrufen

Gerne beantworten wir Ihre Fragen in einem persönlichen Gespräch!


Kontakt aufnehmen

Schreiben Sie uns eine E-Mail mit Ihren Fragen und Kommentaren!