Python-stil: 5 værktøjer til at rydde op i din Python-kode

I teorien er enhver Python-kode OK, så længe den er syntaktisk korrekt og kører som beregnet. I praksis vil du vedtage en ensartet stil på tværs af dine projekter, helst en styret af Pythons egne stilanbefalinger. Den gode nyhed er, at du ikke behøver at gøre dette i hånden. Python-økosystemet indeholder en række forskellige værktøjer, fra det meget fokuserede til det vidtgående, for at sikre, at Python-kildekoden overholder stilkonventioner.

I denne artikel vil vi undersøge fire populære værktøjer til kontrol af Python-kodestilarter, plus en til at omformatere koden for at være konsistent. Python IDE'er som PyCharm eller Visual Studio Code understøtter dem enten indbygget eller med en udvidelse, så de let kan integreres i din udviklingsworkflow.

Pycodestyle

PEP 8 er det dokument, der stavede Pythons kodningskonventioner - alt fra om der skal bruges faner eller mellemrum, når man indrykker (brug fire mellemrum, problem løst) til, hvordan man navngiver variabler og objekter. Pycodestyle er Python-modulet, der kontrollerer Python-kode i forhold til PEP 8-anbefalingerne og leverer en rapport om, hvor den analyserede kode er uden for specifikationen.

Pycodestyle giver ikke automatiske rettelser til problemer; det er på dig. Men Pycodestyle er meget konfigurerbar, så du kan undertrykke specifikke fejltyper eller kun analysere specifikke filer i et kildetræ. Og næsten enhver IDE med Python-understøttelse understøtter også Pycodestyle, så det er det nemme valg for universel kompatibilitet, hvis ikke funktionalitet.

Mange Python-kodeforbindelser kan fungere som moduler i Python, og Pycodestyle er ingen undtagelse. Du kan bruge den til at verificere kode programmatisk, for eksempel som en del af en testpakke.

Bedst til:Grundlæggende verifikation af PEP 8-overensstemmelse.

Autopep8

Autopep8 tager op, hvor Pycodestyle slutter. Den bruger Pycodestyle til at bestemme, hvilke ændringer der skal foretages, og omformaterer derefter koden for at være i overensstemmelse med de foreslåede forslag. Eksisterende filer kan omformateres på plads eller skrives til nye filer. Autopep8 løser også en række andre problemer, der kan krybe ind, såsom oprydning af kode konverteret fra Python 2 til Python 3 eller filer, der har blandede linjeafslutningsmarkører. Og Autoprep8 kan bruges programmatisk til at omformatere kode leveret som strenge.

Bedst til: Konvertering af filer til at være PEP-8-konforme.

Flage8

Flake8 indpakker flere Python-linting- og kodestil-værktøjer i en enkelt pakke. Sammen med PyFlakes, der bruger syntakskontrol til at opdage grundlæggende fejl, og Pycodestyle, som vi diskuterede ovenfor, giver Flake8 et ekstra værktøj til at kontrollere projektets "cyklomatiske kompleksitet" - dvs. antallet af uafhængige kodestier, der findes i programmet . (Cyklomatisk kompleksitet er en potentielt nyttig metric, hvis du f.eks. Vil forhindre, at et basismodul bliver for un-basic.) I slutningen af hver analyse leverer Flake8 en percentilmåling for den samlede kvalitet af den analyserede kode, en praktisk måde at få en hurtig idé om, hvilke dele af en kodebase der er mest problematiske.

Flake8 har også et plug-in-system, så fnug kan kombineres med Git-forpligtelser eller andre automatiserede handlinger - for eksempel for at give problematisk kode til en reformater.

Bedst til:Vurdering af den samlede kodekvalitet med specifikke anbefalinger.

Pylint

Pylint er sandsynligvis den mest anvendte og understøttede Python-linter derude. Ligesom de andre ser det efter fejl og afvigelser fra kodningsstandarder i din Python-kode og tilbyder ændringer for, hvordan disse fejl rettes.

Pylint er også uden tvivl den mest kompletist af kodekontrollen, i den forstand at den kan advare dig om mange problemer med din kode, hvoraf nogle måske ikke engang er relevante i din særlige sammenhæng. Resultaterne kan være detaljerede, men kan også skræddersys, så de passer til særlige forhold i et bestemt projekt.

Pylint ser efter fem gradvis mere problematiske emner. “Konventioner” er overtrædelser af PEP 8 eller andre regler for konsistens i Python. “Refaktorer” angiver kodelugt, almindelige fejl eller kode, der kan omarbejdes for at være mere effektiv eller mindre forvirrende, såsom cyklisk import eller filer med for mange lignende linjer, der kan kondenseres til en fælles funktion. “Advarsler” er Python-specifikke problemer, som f.eks. Uopnåelig kode (alt efter enVend tilbage i en funktion) eller klasser, der mangler en__i det__ metode. "Fejl" er faktiske kodefejl, som udefinerede variabler, og "Fatal" problemer er dem, der forhindrer Pylint i at køre.

Igen, hvad der gør Pylint både mest nyttigt og mest tungt, er mængden af feedback, den giver. Den gode nyhed er, at for dem, der ønsker at indstille det, kan Pylints detaljerethed og granularitet ændres pr. Projekt eller endda pr. Fil. Derudover kan du trække på en række Pylint-plug-ins, der tilføjer specifikke typer kontrol, f.eks. For kode, der er for kompleks (lange kæder afhviss osv.) eller fnug til forældede indbyggede programmer.

Bedst til:Soup-to-nuts kvalitetskontrol for kode, forudsat at du ikke har noget imod at tilpasse dens indstillinger for at undgå overbelastning.

Sort

Sort er ikke et linter- eller kodeanalyseværktøj, men et værktøj til at håndhæve stil som en måde at sikre bedre kodekvalitet. Af den grund sidder den komfortabelt sammen med de andre værktøjer, der er beskrevet her, da det er en måde at undgå mange grundlæggende typefejl på.

Sort beskrives som "den kompromisløse kodeformatering" - kompromisløs, fordi den ikke har nogen indstillelige muligheder undtagen linjelængde. Sort omformaterer Python-kode til en enestående, konsistent og læsbar stil, der trækker på interne regler til håndtering af vanskelige problemer som multiline-udtryk, så selv de bliver omformateret konsekvent.

En udråbt fordel ved at bruge sort er, at den løser alle tvister om formatering, så eliminerer "bikeshedding" og gør også linteroutput mindre støjende. Du behøver ikke diskutere, hvordan du formaterer kode til et projekt eller endda gør meget af det manuelt. Du bruger bare sort og er færdig med det; du kan endda konfigurere mange IDE'er til automatisk at formatere kode med sort. En anden hævdet fordel er, at det gørgit forpligter renere, da det reducerer antallet af ændringer, der bliver foretaget i en given fil.

Bedst til: Piske kodebaser til grundlæggende stilistisk overensstemmelse en masse.