Zitat:
Mit der schwindenen Anzahl an Zeilen erhöht sich die Anzahl selbiger, die auf meinen Bildschirm passen und somit auch meine Effizienz beim Arbeiten . Ich versuche nicht krampfhaft Zeilen zu optimieren, sondern dort, wo es für mich sinnvoll ist.
Siehst du und da haben wir beide komplett gegensätzliche Ansichten.
Du kaufst dir einen 100 Zoll Monitor und quetscht deinen Source so eng wie möglich damit du soviel Source wie möglich auf einen Blick überblicken kannst.
Ich prophezeie dir jetzt das du irgendwan auf so komplexe Probleme stoßen wirst das selbst ein 1000 Zoll Monitor und die Schriftart Arial 6 nicht mehr helfen wird dein komplexes Problem zu überblicken !!
Das Schlimme an dieser Arbeitsweise ist das du eine Spirale damit in Gang gesetzt hast die ins Unendliche wächst und immer weniger effektiv die geforderten Ziele an dich erfüllen lässt.
Richtig wäre es das Problem dialektisch zu betrachten und Stück für Stück auf kleine Probleme zu reduzieren. Je mehr du auf diese Art&Weise das Gesamtproblem zerlegst desto größer und ausführlicher kann der Source für jedes der Teilprobleme werden. Also direkt umgekehrt proportional.
Dh. man baut seinen Source so auf das jedes Modul ein abgeschlossenes Teiulproblem lösst und man somit jedes Teilproblem unabhängig von den anderen separat verstehen und auch testen kann. Dann kombiniert man in einer hierarisch übergeordneten Source alle diese Module um dann das Gesamtproblem zu lösen.
Dies gilt bis hinab zum Aufbau jeder einzelnen Quelltextzeile, also auch die Frage ob das begin auf gleicher Zeile wie if then steht oder ob man versucht hat über die Syntax eines begin end; eine grafische Struktur per Einrückungen in den Source zu bekommen. Die gilt also auch dafür ob man formal Result := Odd(N) and (N > 2) schreibt oder das mit if then Abfragen mechanisch lösst.
Somit benötigt man garnicht mehr den Überblick über alle Source auf einmal. Denn man hat ja Top-Down oder Bottom-Up jedes abgeschlossene Teilstück der Source verstanden, verifiziert und getestet. In dem Moment ist gesichert das die IsPrime() Funktion zb. wirklch korrekt funktioniert und kann so deren Internas vergessen. Es reicht dann einfach IsPrime() in die Lösung des Gesamtproblemes zu integrieren. Quasi "Aus den Augen aus dem Sinn", es interessiert nicht mehr wie IsPrime() intern funktioniert.
Diese Arbeitsweise ist gewichtet hierarisch und benötigt nicht den Zwang alles auf einmal überblicken zu müssen/wollen, und ergo auch nicht den Zwang den Source wenn möglich in eine Zeile zu quetschen. Es ist die Grundlage dafür das man in einem Team arbeiten kann in dem man sich als Einzelner auch nur auf Teilprobleme konzentieren wird.
Und denoch, halte ich dein Argument für irrelevant, denn zähle doch mal die Anzahl an Zeilen deines Sources und meines Sources. Da exitiert kein Unterschied und denoch gibt es gravierende Unterschiede in den Punkten: algorithmische Effizienz, Performance als Program, Struktur im Source, logische Fehlerhaftigkeit.
Programmstil ist die Frage WIE wir programmieren, und da wir das mit unserem Hirn machen, also eine Frage des Denkens. Man kann also eben nicht einen bestimmten Schreibstil in einem Delphi/PASCAL Source lösslösen von der Frage ob derjenige Programmierer in der Lage ist ein Problem gedanklich zu durchdringen.
Trennt man dies so gibt es mehrere Möglichkeiten:
1.) der Programmierer durchdringt ein Problem logisch korekt kann es aber nicht in Source transportieren, weil er einen schlchten Stil hat
2.) der Programmierer hat einen schlechten, unübersichtlichen Stil und kann so ein Problem nicht von unten durchdringen.
Ergo: ein sauberer und gut struktuirerter Source ist gleichmaßen ein Indiz dafür das der Programmierer auch sein Denken logisch strukturieren kann, und finally ein Problemlöser ist.
Nochwas zur Dokumentation der Sourcen per Remarks, etc.pp:
Grundsätzlich widerspricht eine zusätzliche Beschreibung zu einem Source dem Sinn einer höheren Programmiersprache. Der Source sollte absolut selbsterklärend sein. Soweit das ideale Ziel einer idealen Programmiersprache. Aus Erfahrung kann ich aber bestätigen das gute Sources mit deutlich weniger Bemerkungen auskommmen, als schlechte Sourcen.
Es ist also ein Indiz für einen guten Programierstil wenn man mit weniger Remarks auskommt, oder gar mit keinen !
Es gibt kein Indiz dafür das man mit Remarks seinen Programmirstil tatsächlich verbessern würde.
Gruß Hagen