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