Re: "Crash-Kurs BASIC und Dialoge"?
Verfasst: Do, 13.02.2020 22:48
Hallöchen Dirk,
willkommen zurück. Dann geht's Dir jetzt wieder besser?
Man hat vor zwei Wochen meinen Roller gestohlen und ich musste mich erst einmal um ein Motorrad und einen neuen Führerschein bemühen.
... werd' jetzt aber wieder öfter da sein.
Ich habe mir die Datei jetzt eine halbe Stunde betrachtet, aber breche an dieser Stelle erst einmal ab.
Da der Code nun schon etwas komplexer geworden ist, kommt man um eine gute Dokumentation (Kommentare) nicht mehr herum - diese finde ich aber leider nicht in deiner Datei!
Die Kommentare der einzelnen Zeilen stehen außerhalb meines 22 Zoll Monitors. Es ist unfassbar anstrengend, jede Codezeile zwischen zwei Ansichten hin- und herzuwechseln. Selbst mit einem 50 Zoll Monitor ist zuviel Platz zwischen Code und Kommentar, sodass man ein Lineal ansetzen muss, um einen Kommentar der richtigen Zeile zuordnen zu können.
Programmcode sollte grundlegend nicht über einen Bildschirm (1000/1200 Pixel) hinaus geschrieben werden, da er während des Scrollens lesbar sein muss und z.B. auch nicht wenige Entwickler nur einen kleinen Monitor (z.B. mittels Note-/Netbook) benutzen. Die Kommentare gehören in einer vollen Zeile nicht daneben, sondern darüber - so ist auch schon vor einer Codeanalyse die potenzielle Funktion bekannt.
Warum sind in jedem Modul identische Variablen (oOk, oAb, oTAn...) deklariert? Einmal global reicht nicht aus?
Bezeichner können praktisch 255 Zeichen enthalten und dies sollte man auch unbedingt ausnutzen. Den Kontext zu kurzen Bezeichnungen wie z.B. oTAn hast Du in einem halben Jahr nach Abschluss deiner App sicherlich vergessen. In der OOME, Tom's Büchern, und ganz besonders der OpenOffice.org-API-Referenz, ist ganz wunderbar beschrieben, wie man Variablen richtig benennen sollte.
sPrüfeEintragAusDatenbankEvent sagt z.B. mehr aus, als pPEaDE. Dies gilt für Variablen- sowie auch für Funktionsnamen.
Der Funktion wird die Nummer eines Dialog-Tabs übergeben, aber in der enthaltenen Schleife dann damit der Index von Steuerelementen referenziert, um eine Liste von Beobachtern zu (de)aktivieren? Was soll diese Funktion denn genau machen? Hattest du anfangs nicht schon eine korrekte Funktion geschrieben, die sämtliche Listener des aktuellen Dialoges umschaltet?
Erstellung eines Datenarrays bei jedem MousePressed-Event?
Dies wird einen Laufzeitfehler bei niedrigeren OO-Versionen verursachen, da vor nicht allzu langer Zeit noch mit 16 Bit, also nur 65k Zeilen gearbeitet wurde und der Zellenindex somit nicht existiert. Eine effektive Lösung für Zellabfragen mit Unbekannten hatten wir doch aber eigentlich auch hier schon mal diskutiert?
Warum benutzt Du für die Sichtbarkeit von Objekten eigentlich die Eigenschaft .Model.enableVisible und nicht einfach .visible?
.enableVisible setzt nicht die Sichtbarkeit, sondern die Option, Änderungen an ihr vornehmen zu können.
Was bedeutet diese Zeile bzw. was ist ihr Zweck?
Warum wird hier eine Variable für den Titel deklariert, wenn doch der Wert des Titels schon in dem Array-Element vorhanden ist?
Im gesamten Code finden sich hundert solche Variablen, die keinen weiteren Zweck besitzen, als die Lesbarkeit zu verschlechtern und dadurch den Überblick zu verlieren. Jede Variable im Code bedeutet gegebenfalls auch zusätzliche Prüfmethoden, um diese zu validieren - man sollte es deshalb nicht damit übertreiben.
Eigentlich hatte ich gehofft, daß Du verstärkt Funktionen mit Parametern benutzt (um Dir das Leben zu erleichtern), aber die aktuelle Datei besteht fast ausschließlich aus Routinen, die auf hundert globale Variablen zugreifen, bei denen nicht immer sofort erklärt werden kann, wo deren Wert gerade definiert wurde.
Ein einfacheres Beispiel aus der Routine 'Loeschen':
In der Routine F_AnzDatensatz (die Du als Funktion deklariert hast) wird die globale Variable 'anzDat' definiert, um dann mit dieser extern weiterzurechnen. Diese Variable gehört als Rückgabewert in die Funktion F_AnzDatensatz.
Gibt es denn zum Thema Funktionen noch Unklarheiten? Bist Du Dir über den Ausdruck Rückgabewert bewusst?
Ich hoffe, dies war jetzt nicht schon zuviel des Guten, aber Du freust Dich ja stets über konstruktive Kritik.
Vielleicht kannst du zumindest mal deine Kommentare ändern, Du hast damit doch bestimmt auch selbst so deine Probleme?
Noch zwei Bemerkungen zum Schluss:
Die Kommentare in deinem Code waren wirklich Fleißarbeit, aber bedenke bitte, daß ihr einziger Nutzen darin liegt, zu erklären, was im korrelierenden Code-Abschnitt genau passiert - dies fehlt teilweise gänzlich. Ein Kommentar, der besagt, daß eine Variable belegt wird, wäre unter Umständen völlig sinnfrei, da man dies auch an der Variablenzuweisung im Code schon sieht. Interessant für den Analysten wären aber z.B. der Wert/die Art, die Herkunft oder die weitere Verwendung des Variableninhalts.
Wenn Routinen auf unzählige extern definierte Variablen angewiesen sind, sinkt die Lesbarkeit des Codes, was die Fehlerquote zugleich erhöht.
Es wäre wirklich der bessere Weg, vermehrt Funktionen einzusetzen und diese vielen Redundanzen im Code zu vermeiden.
Wie lang hast Du damals eigentlich mit MS Office gearbeitet und was damit gemacht?
Bin dann erst mal wieder weg.
Liebe Grüße,
Marcel
willkommen zurück. Dann geht's Dir jetzt wieder besser?
Man hat vor zwei Wochen meinen Roller gestohlen und ich musste mich erst einmal um ein Motorrad und einen neuen Führerschein bemühen.
... werd' jetzt aber wieder öfter da sein.
Ich habe mir die Datei jetzt eine halbe Stunde betrachtet, aber breche an dieser Stelle erst einmal ab.
Da der Code nun schon etwas komplexer geworden ist, kommt man um eine gute Dokumentation (Kommentare) nicht mehr herum - diese finde ich aber leider nicht in deiner Datei!
Die Kommentare der einzelnen Zeilen stehen außerhalb meines 22 Zoll Monitors. Es ist unfassbar anstrengend, jede Codezeile zwischen zwei Ansichten hin- und herzuwechseln. Selbst mit einem 50 Zoll Monitor ist zuviel Platz zwischen Code und Kommentar, sodass man ein Lineal ansetzen muss, um einen Kommentar der richtigen Zeile zuordnen zu können.
Programmcode sollte grundlegend nicht über einen Bildschirm (1000/1200 Pixel) hinaus geschrieben werden, da er während des Scrollens lesbar sein muss und z.B. auch nicht wenige Entwickler nur einen kleinen Monitor (z.B. mittels Note-/Netbook) benutzen. Die Kommentare gehören in einer vollen Zeile nicht daneben, sondern darüber - so ist auch schon vor einer Codeanalyse die potenzielle Funktion bekannt.
Warum sind in jedem Modul identische Variablen (oOk, oAb, oTAn...) deklariert? Einmal global reicht nicht aus?
Bezeichner können praktisch 255 Zeichen enthalten und dies sollte man auch unbedingt ausnutzen. Den Kontext zu kurzen Bezeichnungen wie z.B. oTAn hast Du in einem halben Jahr nach Abschluss deiner App sicherlich vergessen. In der OOME, Tom's Büchern, und ganz besonders der OpenOffice.org-API-Referenz, ist ganz wunderbar beschrieben, wie man Variablen richtig benennen sollte.
sPrüfeEintragAusDatenbankEvent sagt z.B. mehr aus, als pPEaDE. Dies gilt für Variablen- sowie auch für Funktionsnamen.
Code: Alles auswählen
Function F_KeyListener_Load(anzTab as Integer)
...
Code: Alles auswählen
Function F_MouseListener_MousePressed(oEvent)
...
Code: Alles auswählen
Function F_AnzDatensatz(...)
oCell = oBlatt.getCellRangeByName("B4:B1048576")
...
Warum benutzt Du für die Sichtbarkeit von Objekten eigentlich die Eigenschaft .Model.enableVisible und nicht einfach .visible?
.enableVisible setzt nicht die Sichtbarkeit, sondern die Option, Änderungen an ihr vornehmen zu können.
Code: Alles auswählen
oOk.Label = "Material ä"& chr(126) & "ndern"
Code: Alles auswählen
Dim Titel As String : Titel = A_Dlg(0)
odlg_Dialog.model.Title = Titel
Im gesamten Code finden sich hundert solche Variablen, die keinen weiteren Zweck besitzen, als die Lesbarkeit zu verschlechtern und dadurch den Überblick zu verlieren. Jede Variable im Code bedeutet gegebenfalls auch zusätzliche Prüfmethoden, um diese zu validieren - man sollte es deshalb nicht damit übertreiben.
Du hast in der ersten Zeile des Moduls 'Option Explicit' gesetzt, deshalb musst Du jede Variable deklarieren. Vor der Zeile 205 wurde die Variable i nicht deklariert, was aber eigentlich in der auftretenden Fehlermeldung beschrieben sein sollte!?' !!! Wenn diese Prozedur aufgerufen wird Kommt in Modul Datensatz Zeile 205 eine Fehlermeldung !!!
' F_DatensatzFarbe
Was genau ist deine Frage?'* DAS 2.GRID IST FÜR DEN MATERIAL-BEREICH NICHT NÖTIG ALLERDINGS VIELLEICHT FÜR ANDERE BEREICHE
'* DIE GRÖ?E DES DIALOGES DIALOG_AUSWAHLDATENSATZ ÄNDERT DANN SEINE HÖHE
Allgemein sind viele Deklarationen in der Datei inkorrekt. Hast Du dies in der Dokumentation nicht nachgelesen?Die Deklaration der Arrays ist mir bei der Typ-Zuweisung auch nicht klar (viel versucht, aber nicht dahintergekommen).
Eigentlich hatte ich gehofft, daß Du verstärkt Funktionen mit Parametern benutzt (um Dir das Leben zu erleichtern), aber die aktuelle Datei besteht fast ausschließlich aus Routinen, die auf hundert globale Variablen zugreifen, bei denen nicht immer sofort erklärt werden kann, wo deren Wert gerade definiert wurde.
Ein einfacheres Beispiel aus der Routine 'Loeschen':
Code: Alles auswählen
F_AnzDatensatz
bZe = vZe + anzDat-1
Gibt es denn zum Thema Funktionen noch Unklarheiten? Bist Du Dir über den Ausdruck Rückgabewert bewusst?
Ich hoffe, dies war jetzt nicht schon zuviel des Guten, aber Du freust Dich ja stets über konstruktive Kritik.
Vielleicht kannst du zumindest mal deine Kommentare ändern, Du hast damit doch bestimmt auch selbst so deine Probleme?
Noch zwei Bemerkungen zum Schluss:
Die Kommentare in deinem Code waren wirklich Fleißarbeit, aber bedenke bitte, daß ihr einziger Nutzen darin liegt, zu erklären, was im korrelierenden Code-Abschnitt genau passiert - dies fehlt teilweise gänzlich. Ein Kommentar, der besagt, daß eine Variable belegt wird, wäre unter Umständen völlig sinnfrei, da man dies auch an der Variablenzuweisung im Code schon sieht. Interessant für den Analysten wären aber z.B. der Wert/die Art, die Herkunft oder die weitere Verwendung des Variableninhalts.
Wenn Routinen auf unzählige extern definierte Variablen angewiesen sind, sinkt die Lesbarkeit des Codes, was die Fehlerquote zugleich erhöht.
Es wäre wirklich der bessere Weg, vermehrt Funktionen einzusetzen und diese vielen Redundanzen im Code zu vermeiden.
Wie lang hast Du damals eigentlich mit MS Office gearbeitet und was damit gemacht?
Bin dann erst mal wieder weg.
Liebe Grüße,
Marcel