Code-Desgin Frage

[Luckie]

Ich habe mal eine Frage bzw. will mal eure Meinung hören.

Ich habe hier vor mir eine Prozedur die über eine Bildschirmseite geht. In dieser Prozedur habe ich eine case-verzweigung:

Delphi-Quellcode:

case StrToInt(Line[0]) of
      0: // Filelist files to copy
        begin
          if FindWildcard(Line[1]) then // Wildcard file
          begin
            SourceFilename := FindWildCardFile(Drive + ':\' + Line[1]);
            SourcePath := Drive + ':\' + SourceFilename;
          end
          else // exact file
          begin
            SourceFilename := CutPathname(Line[1]);
            SourcePath := Drive + ':\' + Line[1];
          end;
          TargetPath := CutFilename(ParamStr(0)) + BOOTCDFILESDIR + Line[2] +
            SourceFilename;
          bSuccess := CopyFile(pointer(SourcePath), pointer(TargetPath), True);
          SendMessage(hWnd, CEM_COPIEDFILE, Integer(bSuccess), i);
        end;
      1: ; // Filelist files to expand
      2: // Filelist files - project files
        begin
          SourceFilename := CutPathname(Line[1]);
          SourcePath := CutFilename(ParamStr(0)) + PROJECTFILESDIR + '\' +
            SourceFilename;
          TargetPath := CutFilename(ParamStr(0)) + BOOTCDFILESDIR + Line[2] +
            SourceFilename;
          bSuccess := CopyFile(pointer(SourcePath), pointer(TargetPath), True);
          SendMessage(hWnd, CEM_COPIEDFILE, Integer(bSuccess), i);
        end;
    end;

Jetzt die Frage: Würdet hier den Code in der case-Verzweigung auslagern, damit die Prozedur wieder auf eine Bildschirmseite paßt oder nicht?
Was ist übersichtlicher, das zu zerstücklen oder zusammen zu lassen, auch wenn es dann nicht mehr auf eine Bildschirmseite paßt?

[LoL]

ich würds so lassen wies ist, ist doch übersichtlich

[Luckie]

Das ist ja nicht alles. Davor ist ja auch noch was:

Delphi-Quellcode:

procedure ProcessFilelist(Filename: string; Drive: Char; hWnd: THandle);
var
  Line: TStringDynArray;
  tf: Textfile;
  s: string;
  i: Integer;
  bSuccess: Boolean;
  SourceFilename, SourcePath, TargetPath: string;
begin
  Line := nil;
  i := 1;
  // count files
  AssignFile(tf, Filename);
  Reset(tf);
  while not EOF(tf) do
  begin
    readln(tf, s);
    if (s = '') or (s[1] = ':') then  // skip empty or comment (:) lines
      continue;
    Inc(i);
  end;
  CloseFile(tf);
  // send number of files to proccess
  SendMessage(hWnd, CEM_MAXFILES, 0, i);
  //  process filelist
  i := 0;
  AssignFile(tf, Filename);
  Reset(tf);
  while not EOF(tf) do
  begin
    readln(tf, s);
    if (s = '') or (s[1] = ':') then  // skip empty or comment (:) lines
      continue;
    Line := Explode(DELIMITER, s);

Dann paßt es wie gesagt nicht mehr auf eine Monitorseite.

[SirThornberry]

wenn dus übersichtlicher findest wenns dann eine seite braucht wird ichs mit case machen ansonsten so lassen. mit bissl kommentaren wirds auch übersichtlicher (obwohl eigentlich schon übersichtlich ist)

[LoL]

solang du immer einrückst und du nicht ne auflösung von 800x600 verwendest wür ichs so lassen

[APP]

Hallo Luckie,

im vor-vorletzten c't 17/2003 steht ein interessanter Artikel über
Refaktorisierung (Quelltexte lesbarer machen, S. 204),
soweit ich mich erinnere, wird dort die Theorie vertreten, dass
man auf die "kleinstmögliche Modulgrösse" herunterbrechen soll,
damit der Code lesbarer, und besser anpassbarer wird...
(kommt aus dem eXtrem programming glaube ich, und vom Hausverstand)

Ich selbst mache das mit den Modulen ebenso, allerdings eher nach Gefühl,
d.h. "wichtige" Teile bleiben auch mal zusammen...

Leider kann man in der Delphi-IDE Prozeduren/Funktionen nicht aus- und einblenden...

[sakura]

Hi Luckie,

an solchen Stellen, wenn ich nicht gerade ModelMaker nutze :mrgreen:, präferiere ich die längeren "cases" in eigene Prozedure auszulagern.

An der Uni hat man uns damals auf den Weg gegeben, daß Prozeduren, Methoden, Funktionen mit ca. 25 bis 75 Zeilen Code (für Hochsprachen wie Pascal/Delphi) i.A. die fehlerfreiesten sind. Kleinere verführen schnell dazu, daß man sich nicht ordentlich mit denen auseinandersetzt, weil die ja sooo übersichtlich sind und größere sind halt einfach zu überladen in deren Funktionalität ;-)

...:cat:...

[Luckie]

@sakura: war des jetzt ein "ja" oder "nein"? Muß man denn alles aus dir rausprügeln? :roll:

Das blöde ist, die case-Verzweigung hängt in einer Schleife drin und ich müßte jedesmal noch den Zähler mit übergeben, damit ich weiß, wo ich bin. Und diese parameterliste macht dass dann wohl wieder unübersichtlich. Deswegen neige ich dazu es erstmal so zu lassen.

[Burning_Chrome]

Hi!

@Luckie: ich wuerde es so lassen... zerteilt wirds IMHO eher schlechter lesbar und zu lang ist es noch nicht.

Best_Regards
Burning_Chrome

[sakura]

Wenn Du ModelMaker nutzt (ich glaube nicht), dann lass es so. ModelMaker bietet Dir die Möglichkeit solche Stellen logisch zu trennen.

Wenn Du ModelMaker nicht nutzt, würde ich es trennen. Allerdings hast Du gerade noch einen wichtigen Punkt genannt. Es liegt in einer Schleife. Prozeduraufrufe kosten Zeit. Wenn Du die Schleife also mehrere 1000 Male durchläufst, lass es wieder...

Ja? Nein? Ich weiss es auch nicht :mrgreen: Aber Du hast jetzt ein paar Anhaltspunkte, die Deine Entscheidu7ng unterstützen sollten.

...:cat:...

[Luckie]

Ich rechne mit 150 bis 200 Schleifendurchläufe. Und ich lasse es, wie gesagt, erstmal so.

[APP]

Hallo, Sakura,

Zitat:

Zitat von sakura

...Prozeduraufrufe kosten Zeit...

ich war bis jetzt immer der Meinung, dass der Compiler das "wegoptimiert",
sodass es egal ist, ob man mit Proceduren
arbeitet, oder den Code á la Spagetti schreibt... :?:

[Luckie]

Wie soll er das Verschieben von Parametern auf den Stack weg optimieren? Und zumindest die Rücksprungadresse muß da hin.

[sakura]

Zitat:

Zitat von APP

ich war bis jetzt immer der Meinung, dass der Compiler das "wegoptimiert"

Der Delphi-Compiler optimiert viel und optimiert gerne (neuerdings auch nicht so gut :-(), aber Prozeduren bleiben Prozeduren und werden durch CALL...RET Sprünge gesteuert und Daten werden auf den Stack gepusht etc.

...:cat:...

[Pseudemys Nelsoni]

bin zwar nich der hellste was das coden angeht :o , aber ich würds alles so lassen, dazu gibt es ja eine horizontale scrollbar :mrgreen:

[negaH]

Zitat:

man auf die "kleinstmögliche Modulgrösse" herunterbrechen soll,
damit der Code lesbarer, und besser anpassbarer wird...
(kommt aus dem eXtrem programming glaube ich, und vom Hausverstand)

Tja, keine sehr sinnvolle Strategie, eine eXtrem-isten Strategie.

@Luckie:

Die Case ist der wichtigtste Bestandteil deiner Procedure, also gehört er auch als Kern in deine Procedure. Aber wie ich gesehen habe werden am Anfang Dateien geöffnet und gescannt. Diese Teile würde ich als lokale Subfunktion coden. D.h. ich würde versuchen das Preprocessing und PostProcessing vor/hinter der Case zu minimieren.

Bei solchen "Problemen" nutze ich kerne lokale proceduren, da sie auf den Stack der übergeordneten Hauptfunktion zugreifen können. Im gesammten bleibt also die procedure ein eigenes gekapseltes Modul, nur innerhalb dieser Procedure wird auf lokale Unterfunktion zurück gegriffen.

Delphi-Quellcode:

procedure MainProc;
var
  X,Y: Integer; // globale Vars zu allen lokalen procs
  
  function ScanFile(const FileName): Boolean;
  begin
  end;
 
begin
  ScanFile();
  ScanFile();
  while do
    case do
      1: ...
    end;
  DeleteFile();
end;

Performance: Es ist richtig das jeder CALL Zeit kostet, dies wird aber in 99.99% aller Fälle absolut überbewertet. Dem gegenüber stehen: schlechte und wenig optimierte Algorithmen und schlecht lesbarer Code. Beide Kriterien machen es sinnlos sich über einen CALL mehr oder weniger zu streiten.

eXtreme Programming: Dies ist meiner Meinung nach eine der unsinngisten Erfindungen die es je gab. Ich habe es sehr genau analysiert und getestet. Ein sauber arbeitender und guter Programmierer wird durch solche Techiken stark ausgebremst. Die Qualitätsaussagen die mit eXtreme Programming produziert werden sind nichts sagend. Denn wenn ein Mensch einen kompliziertes Verfahren codiert so entstehen weniger Codierungsfehler als Logische Fehler. Da in den meisten Fällen der gleiche Programmierer auch die Testroutinen codet, werden die gleichen Logischen Fehler auch in den Testroutinen enthalten sein. Somit ist eXtrem Programming am Ende sinnlos und eher noch als schlcht zu bewerten. Erst in großen Entwicklerteams kann man die Aufgaben so verteilen das jeder Coder den anderen quercheckt. Allerdings, auch ohne eXtreme Programming wird dies praktiziert.

Alle anderen wichtigen Taktiken, eg. Arbeitsstil/Planung/Testphasen sind im Grunde genommen richtg, aber eben NICHT neu Erfindungen. Diese Taktiken sind schon sehr alt und wurden in eXtreme Programming integriert. Subtrahiert man dies von eXtrame Programming dann bleibt nur Schrott übrig. Ok, das ist nur meine Meinung nach 4 Wochen intensiver Benutzung dieser Techniken.

Gruß Hagen

[Daniel B]

Zitat:

Zitat von Luckie

Delphi-Quellcode:

procedure ProcessFilelist(Filename: string; Drive: Char; hWnd: THandle);
var
  Line: TStringDynArray;
  tf: Textfile;
  s: string;
  i: Integer;
  bSuccess: Boolean;
  SourceFilename, SourcePath, TargetPath: string;
begin

Hmm, da kann man noch eine Zeile rauskitzeln, kann manchmal entscheidend sein. ;) :mrgreen:

Delphi-Quellcode:

procedure ProcessFilelist(Filename: string; Drive: Char; hWnd: THandle);
var
  Line: TStringDynArray;
  tf: Textfile;
  i: Integer;
  bSuccess: Boolean;
  SourceFilename, SourcePath, TargetPath, s: string;
begin

[Luckie]

@Daniel_B: In der Variablendeklaration? Willst du mich veräpplen? :mrgreen:

@Hagen: Nested Functions oder Nested Procedures sollen aber, so habe ich gehört, der Performance-Killer überhaupt sein.

Letzendlich kommt es hier nicht auf Performance an, der Flaschenhals sind die CD-ROM- (von da kommen die Dateien) und die Festplatten- (dahin sollen sie) Zugriffe. Deswegen auch die Überschrift: "Code-Design".

[negaH]

Zitat:

@Hagen: Nested Functions oder Nested Procedures sollen aber, so habe ich gehört, der Performance-Killer überhaupt sein.

Ach was man nicht alles so hört ?? :)
Wenn man es richtig anstellt und innerhalb der nested Procedure auf keine übergeordneten Variablen zugreift, und sie schön kurz hält dann sind sie öfters sogar besser optimiert durch den Compiler als normale Methoden oder Proceduren. Einzigst der CALLER hat ein PUSH/POP mehr.
Selbst wenn man auf übergeordnete Variablen zugreift, besonders wenn es viele sind dann kann das in der Performance zum Guten umkippen. Es ist nämlich ein Unterschied wenn der Compiler über EBX, und nur einmal EBX pushed, auf 100 solcher Variablen des übergeordneten Stacks direkt zugreifen kann, statt sie mit 100 Parametern einer normalen Procedure zu übergeben. Alles ist relativ, und besonders die Aussagen vieler Experten, so auch meiner :) (aber 15 Jahre Erfahrungen bingen es dann doch wieder :))

Achso: ganz im Gegensatz zu anderen, bin ich der Meinung das Nested Procedures exakt die Guidelines der Modularisierung unterstützen, also ein guter Programmierstil sind. In fact sie sind strenger und besser als ein Object mit 1000 Methoden zu versehen.

Gruß Hagen