Das haben wir schon immer so gemacht!

Schnelle und pragmatische Lösungen für komplexe Probleme zu finden wird immer wichtiger. Wenn die Lösung einem nicht trivial erscheint gibt es oft keinen anderen Weg als entweder den allwissenden Kollegen um Rat zu fragen oder sich selbst auf eine Recherche im Internet zu begeben.

Wissen die Kollegen auch nicht weiter, haben keine Zeit oder die eigene Recherche bietet sich als schnellere Lösung an, endet diese oftmals auf der wohl (unter Softwareentwicklern) bekannten Seite Stackoverflow.

Dort bin ich vor kurzem auf eine interessante Fragestellung gestoßen.

Zefix! Warum funktioniert das nicht?

Ziel des Codes war es, die Zellen einer Tabelle bei erfüllen von gewissen Kriterien unterschiedlich einzufärben. Die Einfärbung sollte wie folgend unterschieden werden:

// KriteriumKeineSpalten
if (Objekt.AnzahlSpalten == -1) {
// ich vermute, dass Objekte mit solch einem Wert keine Spalten besitzen
  Cell.Background = Yellow;
} else {
  Cell.Background = Green;
}

Scheinbar gab es nur bei einem sehr bestimmten Objekt ein Problem bei der Einfärbung. Dieses Objekt konnte wie folgt identifziert werden:

// KriteriumProblemObjekt
Objekt.AnzahlZeilen == 1 && Objekt.AnzahlSpalten == 2

Das Problem

Der Fragende wollte wissen warum sich sein Code komplett anders verhält, wenn er für Debugging-Zwecke eine weitere Zeile Code ausführen lies.

if (KriteriumProblemObjekt)
    Objekt.AnzahlSpalten = 2;  // If I leave this in it works, if I remove it the single cell is not colored
if (KriteriumKeineSpalten)
    DyeCellInYellow();
else
    DyeCellInGreen();

Den Wald vor lauter Bäumen nicht mehr sehen

Auf die Frage des Erstellers habe ich dann damit geantwortet, dass wenn er seine "Test-Zeile" auskommentiert, die If-Abfrage vermutlich komplett anders interpretiert wird.

Und zwar wie folgt:

if (KriteriumProblemObjekt) 
{
  if (KriteriumKeineSpalten)
  {
    DyeCellInYellow();
  } 
  else
  {
    DyeCellInGreen();
  }
}

Wenn nun also das Kriterium "KriteriumProblemObjekt" nicht erfüllt wird, wird die Zelle überhaupt nicht mehr eingefärbt!

Es handelt sich also um ein selbst verschuldetes Problem bei der Code-Formatierung.

Als Antwort auf meinen Lösungsvorschlag (die Prüfung auf "KriteriumProblemObjekt" zu entfernen) bzw. Hinweis, dass die If-Abfrage bei auskommentieren komplett anders interpretiert wird kam eine (meines Erachtens) äußerst interessante Äußerung:

That "one liner" is only for debugging [..]. As I mentioned (and ironically), this line makes it work. This line is ONLY for debugging purposes so I can set a break point where the data is having an issue in the DGV so I can see it go through the code.
I've been coding c/C++/C# for 40 years. Compile and run this and you will see it does work. Best practice has always been 1 line is no brace, multiple uses braces.
Fragesteller

IMHO

Ich denke hier wurde seit "Ewigkeiten", glücklicherweise ohne ernste Konsequenzen, ein falscher Ansatz gewählt. Auch wenn es auf den ersten Blick (eventuell) einfacher zu lesen ist, besteht (wie gesehen) ein deutlich größeres Risiko eines Fehlverhaltens wenn man "mal eben" nur eine Zeile ändert.

Wenn das Fehlverhalten dann auftritt wundert man sich, dass auf einmal nichts mehr funktioniert und such nach dem Fehler an einer komplett falschen Stelle.

Fazit

Nicht jeder kann alles im Blick behalten. Auch wenn es für dich natürlich sofort offensichtlich gewesen ist dass der Code beim Auskommentieren der einzelnen Zeile komplett anders interpretiert wird, kann dir selbst das Gleiche oder etwas Ähnliches passieren.

Unabhängig von deiner Einstellung (bspw. präferierte Code-Formatierung), solltest du also ruhig auch mal deine aktuellen Werte/Vorgehensweisen hinterfragen.

Macht es Sinn, dass du deinen Usus XY noch immer pflegst, gibt es bessere Ansätze oder kann das auch weitere Konsequenzen auf andere Dinge haben?