refactoring von vbs scripten

[EXDW]

heiho

wir haben hier sehr lange und sehr komplizierte scripte in vbs zu liegen, welche auch in vbs bleiben muessen und welche wir immer weiter ausbauen...

was uns stinkt ist
- es wimmelt von globalen variablen
- man muss vorher wissen was wo und wie initialisiert werden muss damit man etwas woanders verwenden kann
- mal ungarische notation, mal keine, und mal etwas undefiniertes
- kein system und struktur dahinter
- man erwartet das eine funktion funktioniert, tut sie aber nicht wenn man vorher eine bestimmte variable auf ein bestimmten wert gesetzt hat usw

wir wollen, sobald wir wieder mehr luft haben, die script neu aufziehen, und da wuerde mich eure meinung interessieren
gibt es design patterns fuer vbs ? {die klassen sind sehr kastriert, daher wirds schwer damit denk ich}
oder noch ein paar andere tipps die hilfreich waeren ?

gruss

[bgdnoy]

die klassen sind sehr kastriert, daher wirds schwer damit denk ich

Klassen gibt's erst ab v5.0, also bei WXP nicht mit an Bord. Damit fällt auch das große Argument für VBS um, daß es "überall vorhanden" ist.

Im Allgemeinen rate ich davon ab, Entwicklungszeit in neue VBS-Projekte zu investieren. Nahezu alle Scriptsprachen spielen mit COM zusammen. Ich sehe keinen Grund, nicht eine "richtige" Sprache zu verwenden. Warum also unbedingt VBS?

Probleme kann man sich sparen, indem man defensiv programmiert. Bei mir läuft das immer darauf hinaus, daß ich C-Programme in VBS schreibe; also fast nur die Features nutze, die ich C auch hätte (Ich prüfe Rückgabewerte statt on error goto, ich verwende Strukuren, ...). Also wäre da vermutlich fast jedes c/c++ pattern zu gebrauchen (wenn man's überhaupt umsetzen kann).

man erwartet das eine funktion funktioniert, tut sie aber nicht wenn man vorher eine bestimmte variable auf ein bestimmten wert gesetzt hat usw

Das kannst du allerdings in jeder Sprache haben. Passiert euch das nur mit VBS? Dann liegt's mit Sicherheit am Programmierer.

[snuggly]

bgdnoy schrieb:

Im Allgemeinen rate ich davon ab, Entwicklungszeit in neue VBS-Projekte zu investieren. Nahezu alle Scriptsprachen spielen mit COM zusammen. Ich sehe keinen Grund, nicht eine "richtige" Sprache zu verwenden. Warum also unbedingt VBS?

Man hat nicht immer die Wahl.
Ich könnte mir vorstellen, dass es sich hier um eine Funktionalität einer größeren Software-Applikation handelt, die das halt genau so als VBS mit definierten Einstprungpunkten will.

Ich kenn da bei uns in der Firma auch sowas - ein System (läuft allein in 2 ganzen Serverschränken) mit dem Scanning, automatischer Eingangsrechnungserfassung auf Templates basierend, Validierungs- und Review-Workflow, Exportmodule für Warenwirtschaft/Buchhaltung uvm. gemacht wird.
Zum Glück hatte ich da nur kurz vor 3 Jahren was mit zu tun.

Hinter den ganzen Validierungen, Exports, Imports und Erfassungstemplates lagen auch viele anpassbare VBS-Skripte die teilweise seeeehr umfangreich waren und genau so wie der OP es beschreibt mit massen von globalen Variablen die meist als Ersatz für Parameterübergaben benutzt wurden. Deutsch/English gemischt und nich wirklich komenntiert etc.
Eine einzige Katastrophe im Prinzip. Da traut sich kaum jemand ran, weswegen wir stark auf den teuren Hersteller-Support angwiesen waren/sind.

Ein Tipp: Wenn es irgendwie möglich ist externe Programme aufzurufen wäre das eine Möglichkeit das Ganze übersichtlicher zu machen.
Was sich gekapselt auslagern lässt in C++/wasauchimmer als Konsolen-Applikation schreiben (in unserem Fall z.B. ein Stammdatenabgleich + Korrektur bekannten Fehlerdatensätzen) und dann aus den Skripten heraus aufrufen. (2 Textdateien rein, eine raus)

[bgdnoy]

die das halt genau so als VBS mit definierten Einstprungpunkten will.

Die Einsprungspunkte werd' ich schon mit was anderem hinkriegen (zur Not durch beinhartes Wrapping), sonst ist das ein bißchen seltsam. Wenn morgen einer anklopft und ein COBOL-Programm haben will, werde ich ihn verjagen. (Da müsste er schon _sehr_ gut zahlen, damit ich mir das nochmal überlege)

Es ist auch heute kein Hacker mehr notwendig, um VBS-Code mit Python-Code zusammenarbeiten zu lassen; das ist kinderleicht. Daß da wirklich jemand ist, der sagt: "Ihr nehmt Visual Basic, Basta", glaube ich nicht (ist aber durchaus möglich).

Da traut sich kaum jemand ran, weswegen wir stark auf den teuren Hersteller-Support angwiesen waren/sind.

Wenn das wirklich so schlimm ist, dann war der Kauf eben eine Fehlentscheidung. Nachher ist man gescheiter.

[snuggly]

bgdnoy schrieb:

die das halt genau so als VBS mit definierten Einstprungpunkten will.

Die Einsprungspunkte werd' ich schon mit was anderem hinkriegen (zur Not durch beinhartes Wrapping), sonst ist das ein bißchen seltsam.

Irgendwie verstehst du das nicht, hm? Also nochmal für dich:

Manchmal hat man keine Wahl, weil die Host-Appliaktion VBS will und nur das.
In Lotus Notes z.B. gab es (als ich das letzte Mal sowas gemacht hab) auch eingebettete Scripte im Hintergrund die VBS waren.
Das Problem dabei: es waren sogar noch abgespecktes VBS - Syntax und Befehle sehr, sehr ähnlich zu orginal VBS aber nannte sich dann "LotusScript" oder so.

Wenn du auf sowas stößt HAST DU KEINE WAHL.
Und wenn dir einer zuhause an die Tür klopft kannst du das ablehnen, klar - wenn dein Chef es von dir will machst du es oder suchst dir einen neuen Job.

[bgdnoy]

Irgendwie verstehst du das nicht, hm? Also nochmal für dich:

Was verstehst du eigentlich nicht an "beinhartem Wrapping"? Habe gedacht, daß das klar ist.

Sonst gilt: Registrier dich (damit ich weiß, mit wem ich rede) oder Schluss damit. Basta. Freilich kannst du auch Posts machen, die sich auf den OP beziehen; aber so ein Herumgeflame ist echt nicht nötig.

EDIT:
Und ja: wenn mein Chef jemals ein COBOL-Programm verlangt, werde ich kündigen. Versprochen.