Code-Desgin Frage

[Luckie]

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

[APP]

Hallo, Sakura,

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 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.

......

[Pseudemys Nelsoni]

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

[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 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.

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?

@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