Direktes return vermeiden warum?

[BlueForge]

Hallo Forum,

es geht um ADO.NET 2.0, strong typed DataAdapter und ein Codeschnipsel den ich im .NET framework gefunden habe.

public virtual int Fill(testDataSet.AnimalsDataTable dataTable) {
  this.Adapter.SelectCommand =
  ((System.Data.SqlClient.SqlCommand)(this.CommandCollection[0]));
  if ((this.m_clearBeforeFill == true)) {
    dataTable.Clear();
  }
  int returnValue = this.Adapter.Fill(dataTable);
  return returnValue; // <-- warum mit hilfsvariable
}

Die Frage ist oben schon zu sehen, warum keine direkte Rückgabe in der return Zeile. Ich könnte zwar den MIDL code zweier Varianten (mit direktem/ohne direktem) return vergleichen, aber einen Grund dafür finde ich nicht, ausser, das auf dem Stack zusätzlich eine Variable liegt, die defacto nicht benötigt wird.

Das Code-Segment ist wie gesagt direkt aus dem .NET framework, ich vermute das es sich dabei um QA-Richtlinien (Exceptionhandling, etc.) handelt, bin mir da aber nicht sicher.

[Th69]

Dies wird meistens eher zu Debugzwecken gemacht (damit man einen Breakpoint auf die Zeile setzen kann und sofort den Rückgabewert sieht).

P.S. Um das .NET-Framework geht es hier aber nicht, sondern um den vom Visual Studio (Datenbankzugriffs-)Designer generierten Code!

Insgesamt ist aber der generierte Code m.E. sowieso nicht wirklich als Anschauungsobjekt zu empfehlen (es ist viel zu viel "Copy&Paste"(sic!)-Code da drin - anstatt daß es in sinnvolle Methoden unterteilt wurde!).
Auch die überflüssigen Klammern dienen nicht gerade zur Lesbarkeit des Codes.
Insbesondere wird immer noch uralter .NET 1.x kompatibler Code erzeugt (anstatt z.B. generische Methoden etc. zu benutzen).
Aber MS sagt sich wahrscheinlich: "Never touch a running system"?!
In professionellen Projekten wird aber eh' meistens ein OR-Mapper verwendet, z.B. LinqToSQL, EF... (aber auch hier sieht der Code nicht immer gut aus, aber deutlich besser als bei den typisierten DataTables und DataAdapters).

[BlueForge]

Vielen Dank für die Info. :xmas1: