Argomenti posizionali vs opzioni in un'interfaccia della riga di comando

Question

Argomenti posizionali vs opzioni in un'interfaccia della riga di comando

#1 da (15 voti)
#2 da (2 voti)
#3 da (0 voti)
#4 da (-1 voti)
#5 da (-1 voti)

4

Considera il seguente programma della riga di comando manage-id . Fa queste cose:

manage-id list                       (list all usernames and user-ids)
manage-id show  <username>           (shows username's id)
manage-id clear <username>           (erases username's id) 
manage-id set   <username> <user-id> (sets usernames id)
manage-id find  <string>             (list usernames whose id contains <string>)

Quanto sopra è un modo per progettare l'interfaccia utente. Eccone un altro:

manage-id --action list
manage-id --action show  --username <username>
manage-id --action clear --username <username>
manage-id --action set   --username <username> --id <user-id>
manage-id --action find  --search <string>

Il primo è un "progetto dell'argomento posizionale" e il secondo un "progetto dell'opzione della riga di comando".

Tendo a preferire la "progettazione di opzioni da riga di comando" per alcuni motivi:

gli argomenti possono essere presentati in qualsiasi ordine
i nomi delle opzioni sono auto-documentanti
rimuove l'ambiguità sul ruolo dell'argomento (ad esempio, nei due comandi manage-id show johndoe e manage-id find john , il secondo argomento riproduce ruoli diversi).

D'altra parte, la "progettazione di opzioni da riga di comando" utilizza "opzioni" che non sono realmente opzionali.

La mia domanda è questa: esiste una scelta di stile raccomandata (e ampiamente seguita) che preferisca uno di questi due stili rispetto agli altri per i programmi da riga di comando di Linux?

coding-standards user-interface command-line

posta rlandster 19.02.2018 - 17:53

fonte

5 risposte

Leggi altre domande sui tag coding-standards user-interface command-line

RESTful URI map to database tables? Programmare meglio programmando meglio? [chiuso]

score 15 · Answer 1

15

La tua domanda è una falsa dicotomia.

La maggior parte dei posti che ho visto usano entrambi. Parametri basati sulla posizione per i parametri richiesti e parametri basati su opzioni per i parametri opzionali. Hai ragione, sì?

risposta data 19.02.2018 - 21:13

fonte

score 2 · Answer 2

Lo stile è in definitiva dettato dalla complessità del controllo necessario. Se hai una sola opzione, è OK usare posizionale. Se ne avete due, comincia a essere discutibile su quale sia la via più comoda da seguire. E per chi? Per te, il programmatore? O per l'utente?

C'è un altro livello: comandi secondari. Ad esempio riferimento alla riga di comando di Git per esempio.

Se crei molte utilità da riga di comando, svilupperai una specie di parser di argomenti che facilita la distribuzione di raccolte di argomenti complesse nel tuo programma e le accederà facilmente dal codice. E quindi sosterrai uno stile di analisi degli argomenti che è universale in tutto il tuo set di strumenti.

Si noti che i valori predefiniti per gli argomenti con nome possono essere uguali. Quindi possono essere opzionali, dipende da te.

Assicurati di supportare una pagina di utilizzo. Se si inserisce un comando non valido, visualizzare una pagina che documenta le opzioni.

score 0 · Answer 3

Non so se questa risposta SO sia linguisticamente autorevole, ma distingue esplicitamente tra:

argomenti - qualsiasi parte di un comando
opzioni - informazioni che modificano il comportamento del comando
e
parametri - informazioni extra (non sono sicuro di come ciò differisca da un'opzione)

score -1 · Answer 4

"La progettazione di argomenti posizionali" ha una (e maggiore) ragione: la semplicità del parser. Questo è il motivo per cui la maggior parte dei comandi MS-DOS viene utilizzata in questo modo: è economica! Non appena entri nei parametri dettagliati, sei fuori da quella fortuna. Quindi, devi usare l'approccio chiave / valore che chiami "design delle opzioni".

Sì, "design delle opzioni" rende l'analisi della riga di comando molto più complessa. E a sua volta ti dà anche più libertà (questo è molto utile una volta generato gli argomenti della riga di comando con una logica sofisticata e vorresti evitare la progettazione di stato).

Nello stesso tempo, come accennato da Paul, non vi è alcuna restrizione per l'utilizzo di entrambi gli approcci nello stesso costrutto (quindi la parte di base è posizionale e la prima è basata su opzioni).

score -1 · Answer 5

My question is this: Is there a recommended (and widely-followed) style choice that prefers one of these two styles over the other for Linux command-line programs?

Hai mai usato effettivamente la riga di comando?!

Non so se ci sia un documento ufficiale che lo suggerisca ma fondamentalmente tutti gli strumenti standard di unix usano argomenti posizionali per argomenti non opzionali.