Donnerstag, 20. Januar 2011, 11:12
Kleine Umfrage zur Angabe von Kommandozeilenparameter
Hin und wieder führen wir hier intern Diskussionen um Standards und Normen, gerade dann, wenn man eigene Software entwickelt.
Auch immer wieder mal ein Thema: Die Angabe von Kommandozeilenparametern, genauer: Die Syntax-Angabe (z.B. bei
Quasi-Standard ist
Nicht ganz standardisiert sind Angaben verpflichtender Angaben, diese werden teilweise als
Über Eure Meinungen zu dem Thema, Euer Handling etc. freue ich mich!
Auch immer wieder mal ein Thema: Die Angabe von Kommandozeilenparametern, genauer: Die Syntax-Angabe (z.B. bei
--help). Einen wirklich einheitlichen Standard, z.B. für Linux/UNIX, ist nicht aufzutreiben, daher ist es ratsam, sich intern einen Standard zuzulegen.Quasi-Standard ist
[bar] zur Angabe von optionalen Parametern, z.B.Usage: foo -o [bar]
| für Alternativen, wie z.B. Usage: foound
... für wiederholbare Parameter oder kontextabhängige Optionen, z.B. Usage: foo add ...
Nicht ganz standardisiert sind Angaben verpflichtender Angaben, diese werden teilweise als
<bar> oder als {bar} geschrieben. Dazu kommt dann noch, wenn diese verpflichtenden Angaben Freitext-Angaben sind, oder eben aus einer vorgebenen Liste stammen sollen, ergo z.B. Usage: foo -b {src|dest}
Usage: foo -b <src|dest>
Usage: foo -b <ipaddress>
Über Eure Meinungen zu dem Thema, Euer Handling etc. freue ich mich!
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Christian Theune
http://docs.python.org/library/argparse.html
Anonym
die "Usage" Zeile sollte auf jeden Fall nicht ausufernd lang sein.
Also eher
Usage: foo -b
und eine Erklärung der für erlaubten Werte weiter unten bei der tiefergehenden Doku, zu finden mit einer Suche nach "-b", als eine ewig lange, ggf. verschachtelte Angabe direkt in "Usage".
Eine drei, vier, fünfzeilige "Usage" Angabe, die am besten noch tief verschachtelt ist, bei der sich manche Optionen gegenseitig ausschliessen und andere sich gegenseitig bedingen, das genaue Format einer einzelnen Angabe ggf. noch kontextabhängig unterschiedlich ist und der "Künstler" das alles mit liebevoll gesetzter Klammerung ausdrücken will, die bringt doch niemandem etwas.
Da brütet der Entwickler am Ende länger 'drüber als über dem Tool selbst, vergisst am Schluss doch noch eine Klammer, übersieht einen Zusammenhang oder stellt ihn falsch dar (das kommt spätestens bei der ersten Überarbeitung, bei der ein neuer Parameter eingeführt wird). Und 99% der "Kunden" springt sofort darüber weg in die Suche, sobald sie so ein Monster erblicken.
Gruss,
Bernd
philipp
Grüße
Philipp
freya
chi
Usage: foo
Im HTML-Quelltext stehen dann die Spitzklammern mit Inhalt, sie sind halt nicht escapet worden …
Dee
Der dings
foo -f default.conf
und in der default.conf stehen dann kommentiert die möglichen Parameter. Das ist flexibler, kürzer und leichter, als bei jedem Aufruf die Parameter im Kopf haben zu müssen. So muss man nur den Pfad zur Datei kennen. Und kann beliebig viele Dateien haben.
MacSpi
Riffer
"Damals auf dem Amiga! Da war das standardisiert! Unter ADos 2.0 da war das Bestandteil des CLI und in den AmigaDocs klar beschrieben. Und völlig geil gemacht! Aber so etwas gibt s ja heute gar nicht mehr..."
/me nimmt sein altes "Bounce"-T-Shirt und schluchzt heulend hinein...