Il n'y a pas de définitions cohérentes des termes "option", "argument" et "indicateur", et il n'y a aucune autorité centrale dans le monde du développement logiciel qui pourrait imposer leur utilisation. Cela se produit avec beaucoup de terminologie: après plus de 30 ans d'utilisation du mot «répertoire», je dois maintenant traiter avec des personnes utilisant le mot «dossier» qui ont été confondues par le nouveau langage de Microsoft.
Il existe différentes manières de parvenir à des définitions consensuelles des termes dans la programmation. Dans le cas de "argument" / "option" / "flag", les manuels canoniques et les tutoriels pour les langages de programmation ont aidé à imposer l'utilisation, tout comme les termes utilisés dans les bibliothèques communes.
Par exemple, les choses que vous mettez sur la ligne de commande après une commande sont souvent appelées "arguments" à la commande, par analogie avec les arguments d'un appel de fonction , et c'est probablement en partie parce qu'elles sont appelées "arguments" dans le manuel C ( d'où argc
et argv
). La argparse
bibliothèque Python aide également à appliquer le terme "argument". Cependant, je les ai également vus être appelés "paramètres".
Le terme "option" est dérivé de "facultatif", ce qui implique qu'ils peuvent être omis. La getopt
bibliothèque C est une utilisation de ce terme. Mais il existe un précédent pour les "options" qui ne sont pas réellement facultatives: par exemple, le argparse
manuel indique que l'on peut créer une "option requise" (bien qu'il indique également que cela est "généralement considéré comme une mauvaise forme"). Les options sont souvent précédées d'un ( -
) ou double ( --
, longue option) tableau de bord, mais il y a des commandes bien connues qui ne nécessitent pas ou à faire exécuter l' utilisation du tableau de bord pour les options (par exemple tar
, ps
et dd
). Une option peut elle - même prendre un argument (par exemple, -w80
et --color=always
), ou parfois plusieurs arguments.
"Les drapeaux" sont, selon mon expérience, les mêmes que les options, mais ne prennent généralement pas d'arguments eux-mêmes et représentent essentiellement des commutateurs booléens marche-arrêt.
Sur une note plus large, puisque chaque programmeur a la possibilité d'essayer de rechercher une façon standard de faire les choses et de nommer les choses, mais peut également réinventer la roue sans trop de frais supplémentaires, la dénomination ne sera jamais cohérente. Et une fois que vous avez documenté votre code, et il est clair quelle nouvelle signification vous avez donnée à ces mots en donnant des exemples, ces noms et ces significations pourraient bien rester s'il y a suffisamment de personnes qui les prennent dans votre code.