Guter Programmierstil

[Maik81ftl]

Hi,

naja, also dass man Low(), High() für Array-Schleifen verwenden sollte, sollte für jeden, der schon länger als 2 Wochen programmiert klar sein. Im anderen Fall wenn sich mal die Grenzen des Arrays ändern kann man im gesamten Sourcecode nach Schleifen suchen, die das Array verwenden.

Setzt vorraus, das der Programmierer von derartiger Function kenntnis hat.

Was die Try anweisungen angeht nun da gestehe ich das ich von dennen null Plan fahre.

Ebenso versuche ich Zeiger und Pointer zu vermeiden, wenn irgendwie möglich. ergo arbeite ich bei jedem Programm ohne.

[Zuck]

Hi,

naja, also dass man Low(), High() für Array-Schleifen verwenden sollte, sollte für jeden, der schon länger als 2 Wochen programmiert klar sein. Im anderen Fall wenn sich mal die Grenzen des Arrays ändern kann man im gesamten Sourcecode nach Schleifen suchen, die das Array verwenden.

Setzt vorraus, das der Programmierer von derartiger Function kenntnis hat.

Eben dieses Vorhandensein der Funktionen sollte Bestandteil jedes Einsteiger-Buchs bzw. -Tutorials sein. Oder - wenn man es in der Schule lernt - vom Professor mitgegeben werden.

wfg Zuck

[Maik81ftl]

Hi,

naja, also dass man Low(), High() für Array-Schleifen verwenden sollte, sollte für jeden, der schon länger als 2 Wochen programmiert klar sein. Im anderen Fall wenn sich mal die Grenzen des Arrays ändern kann man im gesamten Sourcecode nach Schleifen suchen, die das Array verwenden.

Setzt vorraus, das der Programmierer von derartiger Function kenntnis hat.

Eben dieses Vorhandensein der Funktionen sollte Bestandteil jedes Einsteiger-Buchs bzw. -Tutorials sein. Oder - wenn man es in der Schule lernt - vom Professor mitgegeben werden.

wfg Zuck

Zuck. das kannst aber im BSZ-Dippoldiswalde und TurboPascal 7.0 locker mal vergessen. da kahm dies überhaupt net zur sprache. da wurden nur Programme angeschrieben. Delphi und Lazarus hab ich nur durch die vorhandenen TP kenntnisse begriffen. nix mit Buch, Tut oder Prof. nicht mal uni.

[Zuck]

Zuck. das kannst aber im BSZ-Dippoldiswalde und TurboPascal 7.0 locker mal vergessen. da kahm dies überhaupt net zur sprache. da wurden nur Programme angeschrieben. Delphi und Lazarus hab ich nur durch die vorhandenen TP kenntnisse begriffen. nix mit Buch, Tut oder Prof. nicht mal uni.

Auch ich bin ohne Buch & Lehrer ausgekommen. Delphi Hilfe und dann durchs Internet. Dazu braucht es aber viel an Eigeninitiative, Interesse und das nötige Verständnis für die Materie. Viel beim Programmieren ist ja nicht sprachgebunden sondern es handelt sich um Paradigmen, Patterns, etc. Wenn man jene Dinge erst einmal verstanden hat, kann man in praktisch jeder Programmiersprache erfolgreich und fehlerminimierend programmieren.

wfg Zuck

[Socke]

Wenn man jene Dinge erst einmal verstanden hat, kann man in praktisch jeder Programmiersprache erfolgreich und fehlerminimierend programmieren.

Das hat dann aber nichts mit der sprachspezifischen Fehlerbehandlung zu tun , die von VBA ist nämlich echt rudimentär.

[Zuck]

Wenn man jene Dinge erst einmal verstanden hat, kann man in praktisch jeder Programmiersprache erfolgreich und fehlerminimierend programmieren.

Das hat dann aber nichts mit der sprachspezifischen Fehlerbehandlung zu tun , die von VBA ist nämlich echt rudimentär.

VBA zähl ich hier nicht zu den Programmiersprachen
Delphi, Lazarus, C / C++, C#, PHP, Perl, VB.NET, ...

Zuck

[Socke]

VBA zähl ich hier nicht zu den Programmiersprachen
Delphi, Lazarus, C / C++, C#, PHP, Perl, VB.NET, ...

Ob man aus dem Quelltext ein eigenständiges Binärprogramm erstellt oder nur ein Bytecode interpretiert wird oder der Quelltext direkt ist doch vollkommen egal. Zu gutem Schreibstil gehört jedenfalls auch, eine Fehlerbehandlung. Ob man das dann wie MnVisual löst oder doch lieber mit try..Except oder bei Dateioperationen mit dem guten IOResult ist auch egal. Wichtig ist, dass man die Fehlerbehandlung verwendet, wenn es eine gibt.

[Zuck]

VBA zähl ich hier nicht zu den Programmiersprachen
Delphi, Lazarus, C / C++, C#, PHP, Perl, VB.NET, ...

Ob man aus dem Quelltext ein eigenständiges Binärprogramm erstellt oder nur ein Bytecode interpretiert wird oder der Quelltext direkt ist doch vollkommen egal. Zu gutem Schreibstil gehört jedenfalls auch, eine Fehlerbehandlung. Ob man das dann wie MnVisual löst oder doch lieber mit try..Except oder bei Dateioperationen mit dem guten IOResult ist auch egal. Wichtig ist, dass man die Fehlerbehandlung verwendet, wenn es eine gibt.

Natürlich gebe ich dir hier recht, allerdings ist das VBA-Beispiel doch etwas schwammig. VBA (= Visual Basic for Applications) stellt ja keine eigenständige Programme her, sondern stellt die Objektkataloge von Excel, Word, .. für Modifizierungen, Makros, etc. zur Verfügung. Hier liegt das Ziel also nicht unbedingt im Erstellen fehlerfreier Anwendungen (natürlich sollten Fehler vermieden werden), allerdings sind die Operationen, die man mit VBA erledigt, meist so klein und überschaubar, dass man für einen Geschwindigkeitsgewinn darauf verzichten kann.

wfg Zuck

[Socke]

Natürlich gebe ich dir hier recht, allerdings ist das VBA-Beispiel doch etwas schwammig. VBA (= Visual Basic for Applications) stellt ja keine eigenständige Programme her, sondern stellt die Objektkataloge von Excel, Word, .. für Modifizierungen, Makros, etc. zur Verfügung. Hier liegt das Ziel also nicht unbedingt im Erstellen fehlerfreier Anwendungen (natürlich sollten Fehler vermieden werden), allerdings sind die Operationen, die man mit VBA erledigt, meist so klein und überschaubar, dass man für einen Geschwindigkeitsgewinn darauf verzichten kann.

In anderen Worten: Zur Erhöhung der Ausführungsgeschwindigkeit kleiner, gut überschaubarer Skripte kann man auf die Fehlerfreiheit verzichten? Oder meinst du, dass man auf "die Operationen, die man man mit VBA erledigt […] verzichten kann"? Ich hab da leichte sprachliche Schwierigkeiten, mit dem, was du schreibst.

Ich interpretiere so: In VBA könne man auf Fehlerbehandlung verzichten, weil der gut überschaubare Quelltext wenig fehleranfällig sei. Durch den Verzicht der Fehlerbehandlung gewinnt man etwas an Geschwindigkeit in der Ausführung.

Meine Meinung dazu: Die Fehlerbehandlung bildet bei komplexen Berechnungen keinen Geschwindigkeitsverlust, da die Komplexität der Berechnungen ungleich höher ist (Hardware-Limits außer Acht gelassen). Die Sprache ist dabei — wie schon vorhergehend angemerkt — herrlich egal. Weiterhin muss man dann noch zwischen Geschwindigkeit bei gültigen Daten und Ablaufsicherheit bei ungültigen Daten abwägen.

Ein Beispiel aus der Praxis bietet sich bei mir gerade an (durch dieses ich überhaupt erst mit VBA in Berührung gekommen bin): In einer großen Access-Datenbank (ja, ich weiß, Access ist grausam, aber vorhanden und Vorgabe). Die von einem Kollegen verfassten Import-Routinen für CSV-Dateien hatten jegliche Warnmeldungen ausgeschaltet. Die Fehlerbehandlung bestand also aus Ignorieren. Im Zuge anderer Optimierungen habe ich auch den Import neu geschrieben und schon tauchten Hinweismeldungen auf, die besagten, dass einige Daten nicht eingefügt werden könnten — alles richtig und auch so beabsichtigt.
In der neuen Version habe ich dann die Auswahl der Daten entsprechend den Vorgaben eingeschränkt. Dadurch kann die Fehlerbehandlung aktiv bleiben und es werden Meldungen angezeigt, wenn wirklich ein Fehler auftritt.

Ehrlich gesagt, sehe ich in diesem Fall hinsichtlich des Programmierstils keinen Unterschied, ob die Anwendung mit VBA und Access oder mit Free Pascal und Lazarus erstellt wird. Nochmals: die Schwerpunkte der Verwendung einer Sprache stellen keine Anforderungen an den Programmierstil, sondern die Sprache (Sprachbestandteile, -möglichkeiten) selbst.
Wenn man will (meine Unterstützung ist vorhanden), kann man auch einen Programmierstil auf eine bestimmte Menge an Funktionen (zum Beispiel eine Programmbibliothek oder auch HTML-Tags) binden. Zum Beispiel gibt es in der C-Standard-Library (und mit Sicherheit nicht nur dort) einige Funktionen, die aus Kompatibilitätsgründen behalten werden, aber Ursache vieler Fehler sind. Daher ist ihre Verwendung unter Entwicklern nicht gern gesehen.