I min forrige artikel, , vi udforskede, hvordan man opbygger et CLI-værktøj fra bunden. Nu tager vi det næste skridt – hvordan gør du det godt? Til sidst ligger nøglen i brugervenlighed. En veldesignet CLI føles intuitiv, forudsigelig og effektiv for brugeren. Master kunsten med kommandolinjen: Din ultimative guide til at udvikle kraftfulde værktøjer Master kunsten med kommandolinjen: Din ultimative guide til at udvikle kraftfulde værktøjer Til demonstration vil vi bruge , men principperne gælder for næsten ethvert CLI-rammeværk, du måtte bruge. Klik på Python biblioteket Parametre De fleste CLI-værktøjer accepterer input fra brugeren.I de fleste tilfælde er denne input ikke interaktiv - den kommer i form af Det handler om, hvordan værktøjet fungerer. parameters For eksempel den Kommandoen tager mindst to parametre: cp 
 
 
 Vejen til filen eller mappen til at kopiere, og Vejen til destinationen. Det kan også bruges til valgfrie parametre som Det gør det muligt at få en verbose output. -v Generelt er der to typer af parametre: og I de fleste CLI-biblioteker kaldes de krævede parametre (eller positionelle argumenter), og valgfrie parametre kaldes . required optional arguments options Positive argumenter Som navnet antyder, Brugeren angiver værdier i en bestemt rækkefølge, og værktøjet fortolker dem i overensstemmelse hermed. positional arguments For eksempel, hvis den  command expects two positional arguments —  og Brugeren vil kalde det: cp Kilde Destinationerne cp source destination
 Selvom dit værktøj kræver input, er det ofte besværligt (og unødvendigt) at få brugerne til at angive hver værdi manuelt. . if you can provide a sensible default, make it an option instead of an argument For eksempel a Parameteren kan udløse At tvinge brugerne til at huske positionen og altid videregive oplysninger tilføjer ikke værdi - det tilføjer kun friktion. --log-level info Mange argumenter Nogle gange kan et værktøj være nødvendigt et enkelt argument. Et almindeligt eksempel er at angive flere kildefiler til at kopiere til en enkelt destinationskatalog. Dette giver brugeren mulighed for at køre én kommando i stedet for flere: multiple values cp source1 source2 destination
 Der er nogle advarsler - typisk Din kode (ikke argumentparseren) skal håndtere yderligere validering og logik. only one argument valgmuligheder Lad brugerne angive parametre ved navn, ofte i formularen Hvis brugeren ikke angiver en indstilling, bruger værktøjet dets standardværdi. Options --option value For eksempel: --log-level debug
 En speciel slags mulighed er et flag – det tager ikke en værdi. Den blotte tilstedeværelse af flaget forstyrrer en adfærd, såsom at muliggøre verbose output: --verbose
 Valg af navne bør være Det gør det nemt for brugerne at forstå deres formål. clear and descriptive Eksempel på implementering: @click.command()
@click.option('--verbose', is_flag=True)
@click.option('--log-level', default="info")
@click.argument('srcs', nargs=-1)
@click.argument('dst')
def copy(verbose: bool, log_level: str, srcs: tuple[str, ...], dst: str):
   ...
 Nu kan værktøjet kaldes på flere måder: cp --verbose --log-level trace source1 source2 destination
cp source destination
 Korte muligheder Disse er ideelle til scripts, da de er selvforklarende og nemme at forstå med det samme. Men for hurtige, engangskommandoer foretrækker brugerne ofte Som I stedet for Vær selektiv, når du introducerer korte formularer. Ikke alle muligheder har brug for en. Hvis dit værktøj har mange muligheder, vil du hurtigt løbe ud af intuitive bogstaver - især da flere muligheder kan starte med den samme. . short options -v --verbose frequently used options Eksempler på: @click.command()
@click.option('-v', '--verbose', is_flag=True)
@click.option('--log-level', default="info")
@click.argument('srcs', nargs=-1)
@click.argument('dst')
def copy(verbose: bool, log_level: str, srcs: tuple[str, ...], dst: str):
   ...
 Nu arbejder begge former: cp -v source destination
cp --verbose source destination
 Validerer brugerindtastning og fejler hurtigt Et robust CLI-værktøj bør De fleste CLI-rammer understøtter dette mønster. validate user input early Klik kan f.eks. automatisk håndhæve gyldige logniveauer og vejargumenter: @click.command()
@click.option('-v', '--verbose', is_flag=True)
@click.option('--log-level', default="info", type=click.Choice(["debug", "info", "error"]))
@click.argument('srcs', nargs=-1, type=click.Path())
@click.argument('dst', type=click.Path())
def copy(verbose: bool, log_level: str, srcs: tuple[str, ...], dst: str):
   ...
 Du kan dog stadig have brug for I vores Eksempel på: custom logic copy 
 
 
 If there’s  , the destination can be a file or directory. one source Hvis der er flere kilder, må destinationen være en mappe - ellers kan filer overskrive hinanden uventet. Generiske CLI-biblioteker håndterer ikke sådanne tilfælde automatisk, så denne validering skal leve i din kode. Hjælp besked Et godt værktøj giver altid et godt . help message Brugere skal være i stand til at køre noget som til at se: --help 
 
 
 
 Hvilke parametre er tilgængelige Deres betydning Accepterede typer eller værdier (f.eks. gyldige logniveauer) En klar hjælpeseddel sparer tid, reducerer fejl og forbedrer brugerens tillid til dit værktøj. Følg dine økosystemmønstre Endelig føles gode CLI-værktøjer Undersøg andre værktøjer i dit miljø og følg deres konventioner – især for . native naming options and arguments For eksempel i Unix verden, værktøjer som , der og Alle brugte og Som argumentation, med Altid før . cp mv rsync source destination source destination Fuldstændig fortrolighed og fortrolighed med bogstaverne ( For at verbale, for den tilbagevendende, til tør løb, Få dit værktøj til at blande sig problemfrit ind i brugerens arbejdsproces. -v -r -n -h/--help Når dit værktøj føles som en naturlig del af økosystemet, vil brugerne være langt mere tilbøjelige til at vedtage det - og nyde at bruge det. Andre aspekter Ud over parametre og argumenter er der flere andre faktorer, der adskiller en Disse aspekter påvirker, hvordan dit værktøj integreres med scripts, hvordan brugere debugger problemer, og hvor nemt det passer ind i større arbejdsprocesser. Godt Udgangskoder Hvert program returnerer en Denne kode lader opkalderen vide, om programmet lykkedes eller mislykkedes. exit code Efter konvention: 
 
 
 0 means success Enhver værdi uden for nul indikerer en fejl Selvom der ikke er nogen universel standard for udgangskoder, er det god praksis at i det mindste . exit with a non-zero code on any error For bedre sammenhæng overveje at følge konventionerne fra Disse er bredt anerkendt i Unix verden. Avanceret Bash-Scripting Guide Du bør også Indsæt dem i den Når brugere eller automatiseringssystemer forstår, hvad udgangskode 3 betyder, kan de håndtere fejl mere intelligent (f.eks. document your exit codes --help Sturgeon mod STDERR Et velbehandlet CLI-værktøj skelner mellem sine to standardudgangstrømme: 
 
 
 STDOUT – for regelmæssig, forventet output STDERR – for fejl, advarsler eller diagnostiske meddelelser Denne adskillelse gør det muligt for brugere og scripts at håndtere hver stream uafhængigt. For eksempel kan en bruger omdirigere den normale output til en fil, mens fejlmeddelelserne holdes synlige på konsollen: mytool > output.txt
 Eller fjerne fejl: mytool 2>/dev/null
 If your tool writes both data and errors to STDOUT, users will need to filter output manually — and that’s fragile. Især hvis dit værktøjs output forbruges af andre programmer, er det vigtigt at holde STDOUT ren og forudsigelig. Udgangsformat Hvis dit værktøj producerer data, der kan forbruges af andre værktøjer eller scripts, er det klogt at understøtte Formater som JSON og YAML. machine-readable output For eksempel: mytool --output json
 Dette gør automatisering meget nemmere - andre værktøjer kan bruge standardparsere i stedet for at stole på skrøbelige strengeparsning, der bryder, når mellemrum, justering eller punktering ændres. Men ofre ikke menneskelig læsbarhed. Mange brugere vil stadig køre dit værktøj interaktivt. 
 
 
 Standard til menneskelæsbar udgang (næsten formateret tekst) Tilbyde et flag (f.eks. --json eller --format, hvis du vil understøtte flere formater) til struktureret output Nogle CLI-værktøjer giver også , sender smukt udskrevet tekst, når du skriver til en terminal, men JSON, når pipet ind i en anden proces - svarende til hvordan eller opføre sig auto-detection kubectl gh Fejlmeddelelser En god fejlmeddelelse skal være: 
 
 
 
 Klart – angiv, hvad der gik galt Actionable - foreslå, hvordan man løser det Konsekvent - brug den samme tone og struktur i hele Et dårligt eksempel: Error: failed
 Et bedre eksempel: Error: Could not open file '/tmp/input.txt' — file not found.
Hint: Verify that the path is correct and you have read permissions.
 God fejlhåndtering sparer brugerne tid og hjælper dem med at opbygge tillid til dit værktøj. Logging og verbosity Brugere sætter pris på kontrol over, hvor meget information de ser. 
 
 
 
 Stille til minimal udgang Verboose til detaljerede beskeder Debug til udviklerniveau tracing Design dine logniveauer, så brugerne kan vælge den rigtige mængde information til deres kontekst. Når de kombineres med korrekte udgangskoder, gør disse niveauer debugging og automatisering meget glattere. Responsivitet og præstation Hvis din CLI udfører tunge operationer, overveje at give eller For eksempel: progress indicators spinners Downloading files... 45% complete
 Samtidig undgå unødvendige animationer eller output, når værktøjet kører i ikke-interaktiv tilstand (f.eks. som en del af et script). Konklusionen Det er relativt nemt at opbygge et CLI-værktøj. Et godt kommandolinjeværktøj føles naturligt, opfører sig forudsigeligt og forsvinder stille ind i brugerens arbejdsproces. - det tilpasser sig, hvordan brugerne allerede arbejder. good Det er I løbet af denne artikel har vi kigget på, hvad der bidrager til denne oplevelse: 
 
 
 
 
 
 
 Klare og konsekvente parametre, der balancerer enkelhed og fleksibilitet Betydelige udgangskoder, der kommunikerer succes eller fiasko Korrekt brug af STDOUT og STDERR til at adskille data fra diagnostik Læselige og strukturerede outputformater til både mennesker og maskiner Nyttige fejlmeddelelser og forudsigelig adfærd Overholdelse af økosystemets konventioner, så dit værktøj føles bekendt fra første løb I sidste ende deler de bedste CLI-værktøjer et fælles træk: de De starter hurtigt, fejler hurtigt, forklarer sig tydeligt og integrerer problemfrit i større systemer og scripts. respect the user’s time Hvis du holder disse principper i tankerne – klarhed, konsistens og empati for dine brugere – vil dit CLI-værktøj ikke kun Det vil være en fornøjelse at bruge. Arbejde

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Denne lyd er produceret på historiens originalsprog!

Sådan designer du et CLI-værktøj, som udviklere faktisk elsker at bruge

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Meet Octopus Network: HackerNoon Company of the Week

Meet MinIO: The HackerNoon Company of the Week

Meet KuCoin Community Chain: HackerNoon Company of the Week

Yale Media Relations for Entrepreneurs with Journalist Walter Thompson & HackerNoon CEO David Smooke

Meet Octopus Network: HackerNoon Company of the Week

Meet MinIO: The HackerNoon Company of the Week

Meet KuCoin Community Chain: HackerNoon Company of the Week

Yale Media Relations for Entrepreneurs with Journalist Walter Thompson & HackerNoon CEO David Smooke

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps