Sempre più team hanno adottato linters e altri strumenti statici nel loro processo di sviluppo. Alcuni li hanno integrati nell’IDE di loro preferenza, altri li hanno automatizzati eseguendoli come passaggio aggiuntivo nel loro CI. Inoltre, alcuni corrono in entrambe le direzioni.
Che cos’è un linter, allora?
Secondo Wikipedia, linter
è uno strumento che analizza il codice sorgente per segnalare errori di programmazione, bug, errori stilistici e costrutti sospetti.,
Il primo linter fu scritto da Stephen C. Johnson nel 1978 mentre lavorava nel sistema operativo Unix ai Bell Labs. Successivamente, molti altri linter sono apparsi per scopi e linguaggi diversi, non solo C.
I primi linter utilizzati per controllare il codice sorgente e trovare potenziali ottimizzazioni per i compilatori. Ma, nel corso degli anni, molti altri controlli e analisi sarebbero stati inclusi nel processo di linting.
L’uso di linters ha anche aiutato molti sviluppatori a scrivere codice migliore per linguaggi di programmazione non compilati., Poiché non è possibile compilare errori di tempo, trovare errori di battitura, errori di sintassi, usi di variabili non dichiarate, chiamate a funzioni non definite o deprecate, ad esempio, aiutando gli sviluppatori a risolverlo più velocemente e ridurre i bug prima dell’esecuzione.
I linter si sono evoluti
I linter si sono evoluti. Hanno iniziato con quei semplici controlli, ma al giorno d’oggi, stanno diventando sempre più sofisticati. Eseguono analisi statiche, applicano flag di configurazione, controllano la conformità con una determinata guida di stile o regola di sicurezza e molto altro.,
Esploriamo alcuni di questi controlli e come possono essere utili per voi.
Analisi statica
Analisi statica significa che il software automatizzato viene eseguito attraverso il codice sorgente senza eseguirlo. Controlla staticamente potenziali bug, perdite di memoria e qualsiasi altro controllo che possa essere utile.
Se sei uno sviluppatore Python, potresti già conoscere Radon. Può contare le righe di codice sorgente (SLOC), le righe di commento, una riga vuota e altre metriche grezze, ma può anche calcolare un “Indice di manutenibilità”, che può essere molto importante in alcuni progetti.
Questo è solo un esempio., Ci sono molti altri linter che eseguono controlli di analisi statica.
E-book gratuito: clicca qui per scaricare la revisione del codice di decodifica e-book gratuito e le richieste di pull. Ottieni tutti i punti chiave e le best practice per implementare una cultura di revisione del codice.
Codice standardizzazione
Dal https://xkcd.com/1285/
Standardizzare il codice è un ottimo modo per spostare la conversazione in più a livello produttivo., Avere una linea guida e eseguire linter contro la base di codice evita cambiamenti estetici nella richiesta di pull, come sostituire tutte le schede per gli spazi, indentare un’assegnazione variabile o persino interruzioni di riga dopo un dato numero di caratteri.
Massimizzare le modifiche significative porta la discussione su argomenti importanti, come decisioni architettoniche, problemi di sicurezza o potenziali bug.
A proposito, anche i problemi di sicurezza e i potenziali bug possono essere evitati dai linter!
Problemi di sicurezza
Se ti piacciono le rotaie, probabilmente hai sentito parlare di Brakeman., È uno strumento di sicurezza per l’analisi statica. È utile trovare potenziali problemi di sicurezza. Ad esempio, esegue controlli alla ricerca di SQL Injection quando si utilizza #find_or_create_by di ActiveRecord e amici. Aggiunge anche controlli per XSS, opzioni di configurazione e molto altro.
Ruby non è l’unico linguaggio con questo tipo di motore. SourceLevel supporta molti motori per diverse lingue. Frenatore incluso.
Potenziali bug
JavaScript ha alcuni trucchi. Uno dei più famosi è la differenza tra == e ===., È una buona pratica, ed evita molto tempo di debug, usare sempre ===. Se abiliti, ad esempio, ESLint per verificarlo, può dirti quale parte del tuo codice sta usando == e persino sostituirlo per te.
Miglioramenti delle prestazioni
Ogni sviluppatore esperto conosce non solo l’importanza di eseguire software, ma molti trucchi che lo migliorano. Il problema è: che dire dei nuovi arrivati? Come puoi trasmettere questa conoscenza? Anche i programmatori senior possono perdere una tecnica o due. Quindi, perché non lasciare che un software di automazione lo faccia per te?,
Lo sapevate che in CSS, il selettore universale ( * ) può rallentare un tempo di caricamento della pagina? O che i selettori di attributi non qualificati hanno le stesse caratteristiche prestazionali del selettore universale? Evitarli è una buona pratica.
Molti linter includono un controllo delle prestazioni. Possono aggiungere diversi tipi di miglioramenti delle prestazioni per gli sviluppatori esperti e nuovi arrivati. CSSLint è solo un esempio.
E molti altri aspetti
All’infinito e oltre!, Ci sono un sacco di linter per diversi linguaggi di programmazione, file di configurazione, e anche per integrazioni software. Qualsiasi controllo che conta e può essere automatizzato può trasformarsi in un linter.
Se lavori in uno scenario particolare, potresti dover scrivere il tuo linter, anche se non è troppo probabile nel nostro settore. Controlli per le caratteristiche di accessibilità HTML, internalizzazione potenziali errori, errori di grammatica, e molti altri sono già lì, open-source, in attesa di scaricare, configurare, e iniziare a utilizzare.
Vantaggi del linting
Secondo Ferit T.,, linting migliora la leggibilità, rimuove errori stupidi prima di esecuzione e revisione del codice. Ma, come accennato, il linting può eseguire lavori più complessi, come rilevare gli odori del codice o eseguire analisi statiche della base di codice.
Ma, in pratica, quali sono i vantaggi del linting?
Migliora il livello di discussione della revisione del codice
Se la tua richiesta Pull non ha errori di battitura, né variabili inutilizzate ed è conforme alla guida allo stile, la conversazione tende a concentrarsi sul punto di vista dell’architettura. Ecco fatto., Pull Request è un ottimo posto per indicare problemi di prestazioni, vulnerabilità dei titoli o suggerire astrazioni migliori. Non è necessario entrare in quella singola o doppia virgolette o tab vs. spazi discussione. Si tratta di un guadagno di produttività di sicuro.
Fa sembrare il codice scritto da una singola persona
A medio e lungo termine avere una base di codice affidabile che sembra scritta dalla stessa persona è eccellente. Manutenibilità ed evoluzione sono più facili perché tutti tendono a capire ciò che è scritto più velocemente e più preciso., Previene i bug, rende il lavoro più gioioso per gli sviluppatori e accelera il time to market delle nuove funzionalità.
Dà visibilità della salute della tua base di codice
Il tuo codice è sano? Non lo saprai finché non lo misurerai. Un modo interessante per farlo è aggiungere un passaggio nella pipeline CI/CD per misurare l’evoluzione dello stato di salute del codice. Meglio di così, si può agire il più presto possibile quando si vede la sua salute a decadere., Tali azioni possono comportare la creazione di carte di debito tecniche nel consiglio o addirittura sollevare il problema durante la riunione del comitato retrospettivo o architettura agile.
Diffonde consapevolezza e proprietà sulla qualità del codice
Gli sviluppatori esperti possono esaminare un diff e sollevare questioni rilevanti sulla modifica proposta. Probabilmente sanno dove cercare: i nomi delle variabili sono descrittivi? Quante righe prende un metodo? C’è qualche superclasse?
Ma che ne dici dei nuovi arrivati? La conoscenza in una squadra è spesso eterogenea. Significa che non tutti gli sviluppatori sanno cosa guardare oltre il codice., Avere un linter per dire dove gli odori del codice sono automaticamente è un ottimo modo per diffondere questa conoscenza e rendere il team responsabile delle modifiche.
La qualità non è una responsabilità di una sola persona. È essenziale misurare e controllare la qualità del codice nel tempo. Altrimenti, il codice diventa disordinato, il che rallenta lo sviluppo e il time-to-market.,
Controlla i debiti tecnici
Poiché molti linter moderni cercano possibili debiti tecnici, come odori di codice, disallineamenti della guida di stile o codice mal progettato (catene profonde diif dichiarazioni, o metodi troppo complessi, per esempio), linters è correlato al debito tecnico.
Rendere espliciti i debiti tecnici durante il processo di revisione del codice aiuta gli sviluppatori di software o gli ingegneri a individuare, discutere e risolvere il problema prima dell’unione nel ramomaster. È una pratica molto conveniente che controlla gli inserimenti del debito tecnico.,
Automatizza la revisione del codice: SourceLevel supporta + 30 linter per aiutarti a migliorare la qualità del codice. Clicca qui per vedere una demo o iniziare una prova gratuita.
Esempi di linter
Ci sono un vasto numero di linter là fuori. A seconda del linguaggio di programmazione, ci sono anche più di un linter per ogni lavoro. Ad esempio, per il linguaggio di programmazione Go, ci sono ktlint e detekt. Entrambi eseguono un lavoro simile. Lo stesso accade a eslint, un linter progettato per JavaScript. Funziona in modo molto simile a tslint o jshint.,
Linters si è concentrato sulla sicurezza
- Brakeman per Ruby
- Bandit per Python
- Node Security per JavaScript
Linters si è concentrato sulla guida di stile e sulle convenzioni di codifica
- CSSLint., SCSS Lanugine e Sass Panno per Cascading Foglio di Stile
- Gofmt per Andare linguaggio
- Swiftlint per Switft
- rustfmt per la Ruggine
- Credo per Elisir
Linters di Analisi Statica
- pep8 per Python
- Phan o PHP Pasticcio Rivelatore per PHP
- kibit per Clojure, ClojureScript, cljx, e altri Clojure varianti.
- PMD per Java
Conclusione
Linters aiutare a ottenere più produttivi e risparmiare tempo e denaro. Guidano il tuo team verso decisioni migliori (quelle orientate dai dati) e condividono la proprietà sulla qualità.,
A SourceLevel, supportiamo molti linter. Corrono contro ogni richiesta di pull aperta e commentano la riga corretta e archiviano i problemi trovati. Aumenta la produttività e l’efficacia degli sviluppatori.
La chiamiamo automazione della revisione del codice. Ogni repository può avere il proprio file di configurazione e quindi rivedere le richieste pull in base alle regole di guida allo stile scelte.