XEx in die Quellcodeformatierung "eingreifen"?

[sx2008]

Zitat von Mavarik:

So erkenne ich schon am IF, ob es 300 Zeilen tiefer noch ein ELSE gibt.

Da würde ich gerne mal ein Beispiel aus deinem Sourcecode sehen.
Wenn du Probleme hast auf einen Blick den Else-Teil zu erfassen, dann liegt das einfach daran dass du zuviel Code im Then-Teil hast.
Oder wenn die If-Bedingung nicht in maximal 2 Zeilen passt dann macht man etwas falsch.
Hier mal ein kleines Beispiel:

Delphi-Quellcode:

begin
  // prüfe ob Land in franz. Überseegebiet liegt
  if country='GP' or country='MQ' or country='RE' or country='GF' or country='PM' then
  begin
    ...

Diese If-Abfrage ist mit einer Zeile noch überschaubar, aber man braucht einen Kommentar um zu verstehen was das Ganze eigentlich soll.
Und hier die verbesserte Variante:

Delphi-Quellcode:

function IsFrenchOversea(const country:string): boolean;
const
   ll : array[0..4] of string = (
   'GP',   // Guadelupe
   'MQ',   // Martinique
   'RE',   // Réunion
   'GF',   // French Guyana
   'PM'    // Saint Pierre & Miquelion
   );
begin
   Result := StrIsOneOf(country, ll);
end;

begin
  if IsFrenchOversea(country) then
  begin
    ...

Insgesamt ist es mehr Code aber man braucht keinen Kommentar mehr um zu verstehen was da passiert.
Eigentlich wollte ich ein Beispiel bringen mit über 20 Teilbedingungen aber das war mir zu viel Schreibarbeit.

Also wenn eine If-Bedingung zu komplex oder zu lang wird dann packt man sie in eine Unterfunktion!

Das Gleiche gilt auch für den Then-Teil oder den Else-Teil.
Wenn es zuviele Zeilen werden dann ist das ein Zeichen dass hier etwas faul ist ("der Code stinkt").
Dann heisst es die vielen Codezeilen in Unterfunktion auszulagern.

Zitat von Mavarik:

Bin halt daran seit über 20 Jahren gewöhnt... Und kann daher NIE die Formatierung ausnutzen.

Das bedeutet dass du seit über 20 Jahren zuviel Code in eine Methode, Funktion, Prozedur oder Block packst und deshalb immer Probleme mit der Formatierung hast.
Ich kann nur empfehlen die Ursache abzustellen, dann braucht du auch keinen Codeformatierer.

[Der schöne Günther]

Ich dachte grade eine vollkommen selbst definierbare Code-Formatierung sei so ziemlich das Highlight von gexperts?

[Uwe Raabe]

Zitat von sx2008:

Delphi-Quellcode:

begin
  // prüfe ob Land in franz. Überseegebiet liegt
  if country='GP' or country='MQ' or country='RE' or country='GF' or country='PM' then
  begin
    ...

Oder so:

Delphi-Quellcode:

  
uses System.StrUtils;
...
  // prüfe ob Land in franz. Überseegebiet liegt
  if MatchStr(country, ['GP', 'MQ', 'RE', 'GF', 'PM']) then
...

[Furtbichler]

Zitat von Uwe Raabe:

Oder so:

Damit weiß man aber ohne Kommentar auch nicht, was gemeint ist. Das ist ja gerade der Sinn von Clean Code: Selbstdokumentierenden Code schreiben, bei dem jede Methode genau eine kleine Sache macht, die man im Methodennamen beschreibt: Der Code ist ohne Kommentar lesbar und verständlich!

[Uwe Raabe]

Zitat von Furtbichler:

Damit weiß man aber ohne Kommentar auch nicht, was gemeint ist. Das ist ja gerade der Sinn von Clean Code: Selbstdokumentierenden Code schreiben, bei dem jede Methode genau eine kleine Sache macht, die man im Methodennamen beschreibt: Der Code ist ohne Kommentar lesbar und verständlich!

Nach meinem Empfinden geht das hier (solange diese Funktion nicht noch an anderer Stelle gebraucht wird) hart an die Grenze dieses Paradigmas. Wenn ich das wirklich bis zum Ende durchziehen will, dann müsste jede Zuweisung in eine Methode gekapselt werden, die die Absicht hinter dieser Zuweisung im Namen trägt. Dafür bin ich dann doch wohl zu viel Pragmatiker.

Aber gut - hier ein leicht abgewandelter Ansatz, der allerdings aufwändiger zu pflegen ist und wahrscheinlich immer noch nicht den Clean Code Prinzipien genügt (ich mag übrigens die Bändchen nicht):

Delphi-Quellcode:

const
  cFrenchOverseas: array[0..4] of string = ('GP', 'MQ', 'RE', 'GF', 'PM');
...
if MatchStr(country, cFrenchOverseas) then

[Furtbichler]

Zitat von Uwe Raabe:

Nach meinem Empfinden geht das hier (solange diese Funktion nicht noch an anderer Stelle gebraucht wird) hart an die Grenze dieses Paradigmas. Wenn ich das wirklich bis zum Ende durchziehen will, dann müsste jede Zuweisung in eine Methode gekapselt werden, die die Absicht hinter dieser Zuweisung im Namen trägt. Dafür bin ich dann doch wohl zu viel Pragmatiker.

Warum nicht? Wenn dadurch der Code lesbarer wird? Es geht bei Methoden nicht nur um DRY, sondern und vor allen Dingen um Lesbarkeit. Ich will den Code (meinen und den anderer) sofort verstehen und mich nicht durch komische Abfragen hangeln müssen. Was ist so schlimm daran, die Abfrage nach dem Land in eine eigene kleine Funktion mit klarem Namen zu verschieben? Es hat *nur* Vorteile (die paar Pikosekunden Performance lassen wir mal außer acht, obwohl man das mit einer 'inline' Direktive auch noch hinbekommen könnte).

Schau Dir den (deinen) Code an. Extrahiere bzw. markiere in einer Methode, die mehr als 1 Zeile hat die Codezeilen, die genau eine Aufgabe erfüllen.
Sind die Zeilen an sich sofort verständlich, und zwar *ohne* das Du deinem fiktiven Kollegen etwas erklären müsstest?
Ist das Abstraktionsniveau dieser Zeile(n) mit den umgebenen identisch?

Ist die Antwort auf beide Fragen 'Ja', gehe zum nächsten Codeblock. Wenn nicht, refaktorisiere die Zeile(n) und spendiere ihnen eine eigene Methode mit einem Namen, der pragmatisch aber genau beschreibt, was diese Zeile(n) tun.

Sehr beliebt bei bool'schen Termen, denn wer begreift schon sofort, was folgende Zeile bedeutet:

Delphi-Quellcode:

if (Person.Position = Manager) or (Person.Salary>5000 and Person.Age>45) 
  then

Aber das hier versteht jeder:

Delphi-Quellcode:

if IstBonusBerechtigt(Person) 
then

Das die Person ein Manager sein muss oder mehr als 5000 verdient und älter als 45 sein muss, ist für das Verständis der IF-Abfrage irrelevant (wer es dennoch wissen will, schaut eben in der Funktion nach). Aber der Code ist sofort verständlich. Ohne Kommentar.

Und wenn die Änderungsanforderung an 'IstBonusBerechtigt' kommt (weil nun auch Abteilungsleiter in den Genuss kommen), dann weiß auch der Junior-Programmierer, wo er ansetzen muss.

Das man daraus auch eine Eigenschaft der 'Person' machen könnte, sei mal dahingestellt.

Schau Dur mal z.B. den DevExpress Quellcode an: Dort gibt es massenhaft Methoden, die nur aus einer Anweisung bestehen. So schreibt man heute guten Code. Alles andere ist imho Frickelei.

Und eines zum Schluß: Natürlich geht man pragmatisch an die Sache ran. Oder nenne es 'gesunden Menschenverstand ohne Dogma'. Ist doch logisch.