Python-stil: 5 verktøy for å rydde opp i Python-koden

I teorien er hvilken som helst Python-kode OK så lenge den er syntaktisk korrekt og kjører som forutsatt. I praksis vil du bruke en konsistent stil på tvers av prosjektene dine, fortrinnsvis en ledet av Pythons egne stilanbefalinger. Den gode nyheten er at du ikke trenger å gjøre dette for hånd. Python-økosystemet inneholder en rekke verktøy, fra det svært fokuserte til det omfattende, for å sikre at Python-kildekoden overholder stilkonvensjonene.

I denne artikkelen vil vi undersøke fire populære verktøy for å kontrollere Python-kodestiler, pluss ett for å formatere koden for å være konsistent. Python IDEer som PyCharm eller Visual Studio Code støtter dem enten naturlig eller med en utvidelse, slik at de lett kan integreres i utviklingsarbeidsflyten din.

Pycodestyle

PEP 8 er dokumentet som staver ut Pythons kodekonvensjoner - alt fra om du skal bruke faner eller mellomrom når du bruker innrykk (bruk fire mellomrom, problemløsing) til hvordan du navngir variabler og objekter. Pycodestyle er Python-modulen som sjekker Python-koden mot PEP 8-anbefalingene og leverer en rapport om hvor den analyserte koden er utenfor spesifikasjonen.

Pycodestyle gir ikke automatiske feilrettinger; det er på deg. Men Pycodestyle er svært konfigurerbar, slik at du kan undertrykke bestemte typer feil eller bare analysere bestemte filer i et kildetre. Og omtrent alle IDEer med Python-støtte støtter også Pycodestyle, så det er det enkle valget for universell kompatibilitet, om ikke funksjonalitet.

Mange Python-kodelinjer kan fungere som moduler i Python, og Pycodestyle er ikke noe unntak. Du kan bruke den til å bekrefte koden programmatisk, for eksempel som en del av en testpakke.

Best for:Grunnleggende verifisering av PEP 8-samsvar.

Autopep8

Autopep8 plukker opp der Pycodestyle slutter. Den bruker Pycodestyle for å bestemme hvilke endringer som må gjøres, og omformaterer deretter koden for å samsvare med forslagene som er gitt. Eksisterende filer kan omformateres på plass eller skrives til nye filer. Autopep8 løser også en rekke andre problemer som kan krype inn, for eksempel å rydde opp i kode konvertert fra Python 2 til Python 3 eller filer som har blandede linjeavslutningsmarkører. Og Autoprep8 kan brukes programmatisk til å omformatere koden som leveres som strenger.

Best for: Konvertering av filer til å være PEP-8-konforme.

Flake8

Flake8 pakker opp flere Python-liner og kodestil-verktøy i en enkelt pakke. Sammen med PyFlakes, som bruker syntakskontroll for å oppdage grunnleggende feil, og Pycodestyle, som vi diskuterte ovenfor, gir Flake8 et ekstra verktøy for å sjekke den "syklomatiske kompleksiteten" til et prosjekt - det vil si antall uavhengige kodebaner som finnes i programmet . (Syklomatisk kompleksitet er en potensielt nyttig beregning hvis du for eksempel vil forhindre at en grunnleggende modul blir for lite grunnleggende.) På slutten av hver analyse leverer Flake8 en persentilmåling for den generelle kvaliteten på den analyserte koden, en praktisk måte å få en rask ide om hvilke deler av en kodebase som er mest problematiske.

Flake8 har også et plugin-system, slik at linting kan kombineres med Git commits eller andre automatiserte handlinger - for eksempel for å mate problematisk kode til en reformater.

Best for:Vurdering av generell kodekvalitet, med spesifikke anbefalinger.

Pylint

Pylint er sannsynligvis den mest brukte og støttede Python-linten der ute. Som de andre ser det etter feil og avvik fra kodingsstandarder i Python-koden din, og tilbyr endringer for hvordan du løser disse feilene.

Pylint er også uten tvil den mest komplettist av kodekontrollene, i den forstand at det kan advare deg om mange problemer med koden din, hvorav noen ikke engang kan være relevante i din spesielle kontekst. Resultatene kan være verbose, men kan også skreddersys for å passe særegenheter i et bestemt prosjekt.

Pylint ser etter fem gradvis mer problematiske klasser av problemer. “Konvensjoner” er brudd på PEP 8 eller andre konsistensregler i Python. "Refaktorer" indikerer kodelukt, vanlige feil eller kode som kan omarbeides for å være mer effektive eller mindre forvirrende, for eksempel syklisk import eller filer med for mange lignende linjer som kan kondenseres til en felles funksjon. “Advarsler” er Python-spesifikke problemer, som ikke tilgjengelig kode (alt etter enkomme tilbake i en funksjon) eller klasser som mangler en__i det__ metode. "Feil" er faktiske kodefeil, som udefinerte variabler, og "Fatal" problemer er de som hindrer Pylint i å kjøre.

Igjen, det som gjør Pylint til både mest nyttig og tungest, er mengden tilbakemelding det gir. Den gode nyheten er at for de som ønsker å stille den, kan Pylints ordlighetsgrad og granularitet endres per prosjekt eller til og med per fil. I tillegg kan du trekke på en rekke Pylint-plugin-moduler som legger til bestemte typer kontroller, for eksempel for kode som er for kompleks (lange kjeder avhviss, etc.) eller linting for utdaterte innebygde moduler.

Best for:Suppe-to-nuts kvalitetskontroll for kode, forutsatt at du ikke har noe imot å tilpasse innstillingene for å unngå overbelastning.

Svart

Svart er ikke et linter- eller kodeanalyseverktøy, men et verktøy for å håndheve stil som en måte å sikre bedre kodekvalitet. Av den grunn sitter den komfortabelt sammen med de andre verktøyene som er beskrevet her, siden det er en måte å forhindre mange grunnleggende stilfeil på forhånd.

Svart blir beskrevet som "den kompromissløse kodeformateringen" - kompromissløs fordi den ikke har noen innstillbare alternativer bortsett fra linjelengde. Svarte omformaterer Python-koden til en enestående, konsistent og lesbar stil, og tegner på interne regler for håndtering av vanskelige problemer som flerlinjeuttrykk, slik at selv de blir omformatert konsekvent.

En hevdet fordel ved å bruke svart er at den løser alle tvister om formatering, så eliminerer "bikeshedding" og gjør også linteroutput mindre støyende. Du trenger ikke å krangle om hvordan du formaterer kode for et prosjekt, eller til og med gjør mye av det manuelt. Du bruker bare svart og er ferdig med det; du kan til og med konfigurere mange IDEer til automatisk å formatere kode med svart. En annen hevdet fordel er at det girgit forplikter seg renere, siden det reduserer antall endringer som blir gjort i en gitt fil.

Best for: Piske kodebaser til grunnleggende stilistisk samsvar en masse.