[Allegro] Flex-Jobs, OpenSource und Softwaretechnologie

[Thomas Berger]

Lieber Herr Eversberg, lieber Herr Eger,

> Kein Einwand, nur mit Augenmaß. Keine groben Redundanzen, keine überflüssigen
> Synonyme, keine raumgreifenden Namen, keine funktionslose
> Ornamentik, keine Praktiken nur deshalb stillschweigend übernehmen,
> weil es "alle" so machen, sondern selber denken und Unnützes verwerfen.

Soweit d'accord.


> Längliche, vermeintlich "sprechende" Namen verführen nach meiner
> Erfahrung den Programmierer, zu meinen, Kommentare würden sich
> erübrigen. Das tun sie nicht, ein Name KANN i.d.R. nicht soviel aussagen
> wie ein präziser, gut durchdachter Kommentar. Wenn man damit nachlässig
> ist, verdirbt man wieder alles. (Und jetzt lenken Sie nicht ab mit

Nichts gegen Kommentare, aber ein Variablenname muss sprechend
genug sein, damit ich ihn in der Fremde, weit weg von seinem
Herkunftsort mit Annotation, wiedererkennen kann. Je "globaler"
eine Variable also eingesetzt wird, umso sprechender sollte ihr
Name sein, etwas, das nur in einem Kontext von fuenf Zeilen genutzt
wird, darf gerne $i oder $xy heissen.


> Querverweis auf meine Namenspraxis, ich *weiß*, daß die auch nicht gut
> ist.) UND: Kommentare komplett in 7-bit ASCII, um allem Ärger mit
> Editoren zu entgehen.

Bei Kommentaren sehe ich nicht unbedingt ein Problem.
Bei Variablennamen schon eher, ganz bestimmt aber bei Inhalten.

Sehr wichtig ist m.E., dass solch eine Job- oder Flexdatei (wie
uebrigens auch die Parameterdateien) konsistent codiert ist,
im Zweifelsfall also nicht


  (ansi codiert)
mess Das möchte ich nicht!

sondern

  (ascii codiert)
var "Das möchte ich nicht!"
ansi
mess

Dies als Beispiel, *wenn* die Datei "ASCII-codiert" (praeziser: DOS-
Ostwest-codiert, vorzugsweise CP850-codiert) sein soll (man koennte
sie aber auch komplett ANSI-codiert gestalten?).

Wichtig wird das dann, wenn nicht nur Benutzerdialoge abgehalten
werden, sondern auch konkrete Vorbelegungen von Variablen oder
Datensaetzen im Job oder Flex erfolgen, ein Mix verschiedener
Zeichencodierungen in einer Datei ist eine Zeitbombe, wenn man
diese Steuerdatei jemals maschinell transformieren will...

Ich wuerde ja im Datei-Header einen (optionalen) Kommentar zur
Zeichencodierung vorschlagen, dann gibt es einen standardisierten
Ort, wo man sich informieren kann, wenn Unklarheiten aufkommen.


> Aber keinen langen Standard-Kommentar-Sermon im Kopf, mit Lizenz und
> Änderungs-Protokoll und Danksagungen und allem! Was da nicht unbedingt
> stehen muß, weil für die Aufgabe wichtig, ganz nach unten. Meine Praxis
> ist da sehr streng begrenzt auf 2,3 Zeilen, aber dafür konsequent, und
> dann geht's sofort zur Sache.

Was *ist* denn Sache? Wenn ich die Datei von vorne nach hinten
lesen muss fuer den Code und von hinten nach vorne fuer die
zugehoerige Dokumentation, dann ist mein Verstaendnis gehindert.

Nach meinem Verstaendnis gehoeren in den Kopf:

* Der Name, Versionsinformationen, irgendein nuetzlicher Hinweis
  darauf, was sie tut.

* (gerade im Open-Source-Fall) Hinweise auf die Lizenz (und wo sie zu
  finden ist), und dazu gehoeren zwar nicht "Danksagungen", wohl aber
  ggfls. Hinweise auf uebernommenen Code und dessen Lizenz, und natuerlich
  auf Autoren. (*Prominente* Hinweise in jeder Datei zu geben *ist*
  verpflichtender Bestandteil vieler Lizenzen)

* Die Dokumentation des "Interfaces", also welche aufrufbaren Dingsdas
  die Datei enthaelt, welche globalen Variablen sie erwartet / nutzt
  etc. Und im Fall von Jobs auch die Exitcodes, ggfls. auch
  Aufrufbeispiele.

* (das tut wirklich jeder ausserhalb Braunschweigs): Raum fuer "private"
  Memos, d.h. "ich habe den Auslieferungsstand geaendert und meine
  Aenderungen fuers spaetere Wiederfinden durch mich selbst mit xy
  gekennzeichnet"


Nicht in den Kopf gehoeren:

* Change histories

* Dokumentation einzelner Routinen oder Datenstrukturen (die stehen
  jeweils vor dem Code)


In srch.job/update.job ist das nicht ganz nach meinem Geschmack, zum
einen hatte ich experimentiert, ob man javadoc oder irgendeines
dieser gaengigen(?) IDEs oder Dokumentationstools (ich erinnere mich
nicht mehr) etwas anfangen kann, zum anderen fuehrt der Schalter -?
dazu, dass der Job sich selbst einliest und einen definierten Abschnitt
des einleitenden Kommentars als "Usage: ..." ausspuckt.

[Etwas, wie etwa Aufrufschalter oder Versionsnummern, an zwei Stellen
pflegen zu muessen, klappt erfahrungsgemaess nie...]


> Hinsichtlich a99/alcarta ist ja die Gefahr von Interferenz mit anderen
> FLEXen virulent, in acon nicht. Da wäre es gut, die unverzichtbaren
> #u-Variablen besser formal zu differenzieren als mir das bisher
> gelungen ist.

Bei acon ist es genauso virulent, wenn man eben nicht die typische
Webanwendung mit adhoc zusammengebautem Job im Sinn hat, sondern
Batch-Szenarios, wo statische Job-Dateien mit beliebigen Export-
parameterdateien (und beim Speichern auch den Indexparametern)
kooperieren muessen.

Ich persoenlich nutze gerne (aber nicht durchgehend) vier Klassen von
#u-Variablen:

#uxy   - fuer Dinge, die so gestaltet sind, dass sie nicht
         unterbrochen werden, also Abarbeitung eines Datensatzes
         in einer Parameteratei

#uXy und #uxY  fuer "Kommunikation mit mir selbst", also etwa
     Zaehler, die von einem Datensatz zum naechsten fortgeschrieben
     werden, oder Werte, die im Zuge der Abarbeitung eines ak-
     Statements belegt werden, aber auch in spaeteren ak-statements
     genutzt. (Mag sein, dass ich die beiden Faelle #uXy und #uxY
     manchmal unterscheide, etwa wenn Export und Parallelexport
     kommunizieren, oder die komplexen Wechsel in Updates mit
     GM-Abschnitt)

#uXY wirklich global (die ganze a99-Sitzung betreffend, oder
     Kommunikation von Parameterdatei mit Flex, Indexparameter
     mit avanti-Job)


> Also etwa festlegen, für welche Zwecke man die Namen mit Großbuchstaben
> oder bestimmten Zeichen an der zweiten, dritten, oder zweiten UND
> dritten Position reservieren will. In den älteren Standard-FLEXen
> wären ja viele Variablen neuerdings besser mit $-Namen aufgehoben,
> aber das wäre eine Fleißarbeit... Man muß ja sehen, daß FLEX seit 1998
> peu à peu entstanden ist, nicht alle Möglichkeiten waren von Anfang
> an da.

Man wird diese Dateien irgendwann sowieso alle anfassen muessen, z.B.
um herauszufinden, was sie eigentlich tun wollen/sollen...

viele Gruesse
Thomas Berger