[Allegro] Order: Sortiercodes in #9A

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

> Vielen Dank erst mal. Möchte aber doch drauf hinweisen, daß Ihre
> Version, allen anerkennenswerten Verdiensten zum Trotz, den vierfachen Umfang
> hat, wegen exzessiver Kommentare und übertrieben langatmiger
> Variablennamen. Je länger ein Name, umso mehr Möglichkeiten
> zum Verschreiben! Da sollte sich doch wohl einiges noch
> kürzen lassen. Mehr als die doppelte Länge ist inakzeptabel.

die doppelte Laenge von was? von Ihrem "frugalen" (s.u.) srch.job
unter Beruecksichtigung dessen, was nicht drin ist aber rein gehoert?
Oder "mathematisch", indem die gezippte Datei maximal 50% kleiner
sein darf (bei Textdateien ist das schwer hinzubekommen wegen
der Praedominanz der Zeichen zwischen 32 und 126)?


> Wozu denn z.B. $OPTS.JobName noch *zusätzlich* zu $ARGV.j usw?
> Beide sind unnötig lang, $-j oder #uoj würde reichen und wäre intuitiv
> sofort der Option -j zugeordnet. Meinethalben noch $_j, wenn Ihnen das
> Minuszeichen zu bedenklich scheint. Für jeden, der so eine Datei
> überhaupt betrachten wird, ist das lang und verständlich genug!

Das hatte ich neulich dargelegt: Das eine ist eine voellig abstrakte,
auslagerbare Verarbeitungsmimik fuer Kommandozeilenparameter, das
andere sind dann sprechende Namen, moeglichst unter Nutzung der
(umstaendlich langen ;-) Benennungen in a99.ini. Und nur diese
Namen nutzt dann der Job in seinem Kern, Anwendervariable nach
Moeglichkeit ueberhaupt nicht, denn diese koennten ja mit der/den
frei waehlbaren Parameterdateien aus dem Aufruf oder den Indexparametern
der aktuellen Datenbank in Konflikt stehen.


> (Unsere Datei hat noch kaum $-Variablen, weil die erst später
> erfunden wurden, nebenbei bemerkt, nicht weil wir dagegen wären.)
> 
> So paßt es nicht zum allgemeinen, frugalen Stil unserer Dateien, ich
> werde in die V30.7 vorerst nur unsere Version reintun.

Ich sehe durchaus Berechtigung fuer beides (allerdings nicht in *einer*
Distribution): Ihre Dateien sind aus verschiedenen Gruenden (Experiment
mit neuen Features, paedagogischer Ansatz, schnelles Prasentieren von
"Loesungen") notgedrungen skizzenhaft und (vgl. die eingestreuten
Kommentare "hier aendern fuer ...") unterstellen Anwender, die notfalls
zum Editor greifen und Anpassungen vornehmen. Problematisch wird es
dann, wenn Anwender fehlende Funktionalitaet oder aehnliches monieren,
dann wird punktuell korrigiert und nach einiger Zeit stellen die
Dateien dann zwar nicht mehr 80%-Loesungen, sondern 85%-Loesungen dar,
und der instruktive Kern ist oftmals in spaeteren Ueberlagerungen
und vorbereitenden Standard-Behandlungen nicht mehr zu erkennen.

Mein Ansatz ist eher universell und defensiv: Alle denkbaren (ich arbeite
noch daran: und undenkbaren) Faelle legitimen und illegitimen Aufrufs
und Nutzung sollten beruecksichtigt sein, die Datei sollte fuer den
Benutzer als Black Box genutzt werden, Aenderungen (abgesehen von
Fehlerkorrekturen) sind eigentlich nicht gewuenscht (d.h. die Notwendigkeit
einer Aenderung durch Anwender wuerde ich als Bug im Design auffassen).
Mein Code sollte nsowohl gruendlich "(100%-Loesung"), als auch nachvollziehbar
(also - auch punktuell - lesbar) sein. Insofern wird "mittendrin" auch oefters
mal auf den Erfolg von Anweisungen getestet und denkbare Abkuerzungen
(Schalter "-j" wird im Job nicht benoetigt und daher nicht ermittelt)
werden zugunsten von Universalitaet und logischer Kapselung manchmal
bewusst nicht genutzt.


> Zumindest bestehen wir auf der Konvention, daß die ersten zwei Zeilen
> Name und Entstehungsdatum enthalten sowie einen Kurzhinweis zu Sinn und
> Zweck der Datei, nicht irgendwelche kryptischen, auskommentierten
> Sachen, die nichts zur Sache tun.

Sie meinen

// $Id: srch.job 23295 2010-06-17 08:38:53Z ThB $
// $HeadURL: https://svn.extra.gymel.com/repos/allegro/acxt/aconjob/trunk/srch.job $

Ich habe noch

// srch.job fuer acon als Ersatz von SRCH.EXE

drueber gesetzt. Ueber Sinn und Unsinn manuell eingetragener Datumsstempel
in sich haufig aendernden Dateien mag ich eigentlich nicht schon wieder
streiten.


> ("Fasse dich kurz!" las man früher an Telefonzellen. Nicht nur das ist
> verschwunden, sondern mitsamt den Zellen auch das Kurzfassen selbst.)

1985 haben Sie die Parameterdateien Ihren Anwendern moeglicherweise als
"aural update" noch telefonisch verlesen (aber ob vom oeffentlichen
Fernsprecher aus?), aus Gruenden der Wartbarkeit halte ich die Gleichsetzung
"Redundanz (Kommentare, sprechende Variablennamen, ...) = boese" aber fuer
verfehlt. Wichtig ist natuerlich der Einwand, dass die Redundanz nicht selbst
zu einem Divergenzproblem werden darf, etwa indem ein Kommentar etwas anderes
behauptet als der von ihm kommentierte Code (inzwischen) tut. Oder wenn der
Kopf von Parameterdateien, die stark auf Features von V27 von 2007 aufbauen,
als letztes Aenderungsdatum 2003 und V23 behauptet...

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAkxSugkACgkQYhMlmJ6W47PfsQQAg9YfMPq8MwLpsFdfBGmLUniP
wVtNhxQo/9KgmAqEESq+WgQAsIvUKpvsVcsou3ckxm3rMFn7Y+ap213yNA1W9baU
4hXwwl8VqCoqSfKOx8F0dWqnkhJ9U/J6qpAfPGhVORiEzUzWSS1CvcNW7PvKs15V
tI928b0HEKguuzLui7c=
=Ln3n
-----END PGP SIGNATURE-----