[Allegro] Flex-Jobs, OpenSource und Softwaretechnologie

[Bernhard Eversberg]

Am 20.12.2011 13:22, schrieb Anando Eger:
>
> dann sollten wir mal "design rules" für flex-Dateien festlegen -
> was meinen Sie?
>
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.

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
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.
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.

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.
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.

Also, dann machen Sie mal mit diesen Vorgaben einen Entwurf.

B.E.