Che dire del linting del codice?

Che dire del linting del codice?

Qualche tempo fa aiuto uno sviluppatore junior, che ha un problema apparente sul suo codice, per scoprire cosa c’era di sbagliato su di esso. Ha installato un lanugine e scaricato (Dio sa perché) un dizionario personalizzato per esso. Ho preparato un piccolo ambiente di test e gli ho mostrato la differenza tra diversi test, in diversi punti e alcune limitazioni di ciascuno (su questo piccolo ambiente).

Recentemente stavo parlando di test con un collega e mi sono ricordato di questo aneddoto e mi sono detto di scrivere un post su questo come potrebbe essere interessante per molti.,

Che cosa è linting?

Linting è il controllo automatico del codice sorgente per errori programmatici e stilistici. Questo viene fatto usando uno strumento lint (alias linter). Uno strumento lint è un analizzatore di codice statico di base.

Il termine linting deriva originariamente da un’utilità Unix per C. Ci sono molti linter di codice disponibili per vari linguaggi di programmazione oggi.

La programmazione Lint è un tipo di controllo automatico. Può accadere all’inizio dello sviluppo, prima delle revisioni e dei test del codice. Questo perché i controlli automatici del codice rendono i processi di revisione e test del codice più efficienti., E liberano i tuoi sviluppatori di concentrarsi sulle cose giuste.

Molti strumenti di test automatici sfruttano un linter incorporato per generare errori, impostare un punteggio sulla qualità del codice e bloccare la compilazione o una fase di distribuzione se questo punteggio è inferiore a quello desiderato (automaticamente o mettendo in pausa il processo lanciando una notifica per verificare manualmente se questi “errori” devono essere corretti o meno).

A cosa è destinato?

Linting ha lo scopo di ridurre gli errori e migliorare la qualità complessiva del codice di sviluppo, accelerare lo sviluppo e ridurre i costi trovando errori in precedenza.,

Quando usare il software Lint?

Se questo è nuovo per te, potresti essere un po ‘ pubblicizzato con lint a questo punto, ma non sono uno strumento programmagico. Un lint è semplicemente uno script “scrapper” / lettore di file con un file (di solito un json o xml) con regole predefinite (o personalizzate) su come deve apparire il codice. In effetti gli IDE hanno un Lint incorporato che ti genererà un errore (cioè se chiami un metodo inesistente, o se provi ad aggiungere un valore stringa in una variabile intera) o un avviso (cioè, se dichiari una variabile all’interno di un condizionale e poi restituisci quella variabile alla fine del tuo metodo). Ma non sto parlando del codice incorporato lint, poiché questi linter sono “morbidi” e permissivi, altrimenti molte persone non useranno quegli IDE, vedremo perché più tardi.

È possibile utilizzare un Lint specifico se si inserisce in queste istruzioni:

Quando si utilizzano linguaggi di programmazione interpretati.

Alcune lingue sono più adatte per il linting del codice rispetto ad altre. PHP, Python e JavaScript sono linguaggi interpretati, questo significa che mancano di una fase di compilazione*., Quindi l’utilizzo del software lint è efficace per garantire uno stile di codifica coerente e risolvere gli errori di codifica di base in questi casi.

Ma, quando si tratta di linguaggi compilati, come C e C++, l’uso del software lint potrebbe non essere sufficiente. C e C++ sono complessi e possono richiedere un’analisi del codice più avanzata.

* Potresti gridare Compilo JavaScript! ma in realtà non è vero. Al giorno d’oggi sul front-end stiamo usando strumenti come bundler, aggiungendo alcuni strumenti javascript che passano il nostro js da alcune fasi come minify, ugglify, ofuscate. Alcuni di questi strumenti eliminano anche il codice inutilizzato sul suo output., Ma nessuna di queste cose significa che stai compilando javascript, poiché l’output sarà a .file js comunque; nessun bytecode, nessun assemblatore.
È vero che puoi convertire javascript in assembly web ma non è un percorso diretto da uno all’altro; devi convertire il tuo js in qualcosa di “compilabile” come il codice C e quindi compilarlo in assembly web.

Quando usi le regole standard
Questa è un’affermazione un po ‘ complicata., Su un linguaggio di programmazione non sarai in grado di usare qualcosa che non è incorporato nel tuo linguaggio di programmazione (questo non è affatto vero, dato che puoi aggiungere librerie o lanciare comandi di sistema dai linguaggi di programmazione, ma comunque Lint non ha nulla a che fare con questo…)
Quali regole standard rappresentano?
L’utilizzo di un framework si adatta bene qui, è necessario utilizzare i metodi integrati del framework per raggiungere l’output desiderato.
A volte le regole standard significa codice alla moda., Queste metodologie e soluzioni alternative che la comunità ripete come un mantra finché non trovano un altro modo alla moda per raggiungere l’obiettivo di un determinato compito, o fino a quando qualcuno con ripercussioni pubbliche dice alla comunità “ehi, stavo analizzando queste soluzioni alternative e trovo che c’è un modo migliore per raggiungere questo per questo motivo” e poi la comunità va avanti.

Quando le vostre esigenze sono di base
Strumenti Lint sono grandi per l’analisi di base. Ma se hai bisogno di analisi più sofisticate devi guardare altrove (strumenti di test automatizzati e sviluppo basato su test).

Dove dovrei vedere una lanugine?

1., Nei test automatizzati (li chiamiamo automatizzati perché vengono eseguiti automaticamente ma qualcuno deve codificare il test per ogni caso d’uso su un’app) come Cypress, è possibile aggiungere un lint per segnare la qualità del codice.

Questo può essere eseguito in tempo di sviluppo (quando lo sviluppatore preme il pulsante test) o probabilmente nella fase di distribuzione. Ad esempio, quando spingi qualcosa nel ramo master potrebbe essere un trigger per aumentare i test, incluso il lint, e bloccare la distribuzione (e incolpare te) se hai fatto qualcosa di sbagliato, allora dovrai riparare o trovare il bug (questo non significa che sia colpa tua., Potrei spingere un’API che fa sì che il tuo client si blocchi ricevendo valori inaspettati, e questo sarà colpa mia, non tua).

Questo test non ha lo scopo di biasimarti ma di aiutare nel processo di sviluppo, di solito è meglio trovare un bug prima di integrarlo nella fase di pre-produzione a causa di un errore di test piuttosto che trovarlo di sorpresa in produzione.

2. Su grandi progetti, di solito su grandi aziende., Se sei in una società molto grande, il project manager dovrebbe gradire che tutto il codice assomigli allo stesso (formattazione), quindi probabilmente hanno un lanugine da qualche parte che ti punti se hai aggiunto 4 spazi bianchi per indentare qualcosa che vogliono con 2 e questo ti biasimerà se non hai dichiarato un metodo con il caso camel per esempio.,

Trovo i toni degli sviluppatori junior che cercano di combatterlo perché a loro piace una formattazione particolare, ma senza questi strumenti, queste grandi app software sembreranno un mostro di Frankenstein in un futuro aumentando la difficoltà di leggere tutte le parti o seguendo alcuni percorsi di metodo e sostituzioni di classe. Pensate su di esso come la lettura di un libro su cui ogni paragrafo ha una diversa font-size, font-famiglia e così.

Dove non usarlo?

Questo punto è così semplice: non usarlo su contesto dinamico e su linguaggi non di programmazione.

1. Il primo è facile da capire., Se sei in un contesto dinamico, il lint (un correttore statico) non conoscerà mai il risultato finale e ti incolperà per le cose che sono OK, aggiungerò qualche esempio sul prossimo punto.

2. Questo dovrebbe sembrare ridicolo, ridondante o puoi dirmi ” Dove usi un lint se non è su un linguaggio di programmazione?”

Mulder, ci sono linter HTML e CSS là fuori.

Sì.. ehm um.. Ma, come?,

Beh, non sono linters in verità, sono solo il codice-dama, lo stesso si può fare con il validatore del w3c, ma invece di copiare il tuo codice in un validatore, di solito eseguire in tempi di sviluppo dò la colpa a te per cose diverse, basate su someones parere, che è fastidioso, imprecise e davvero non si adatta oggi l’utilizzo di queste due tecnologie (o tre, se si aggiunge SCSS), e più importante, di solito non hanno un motivo per ogni istruzione, o le ragioni contraddicono da un punto ad un altro, o il motivo è obsoleto, o i motivi per cui non sono applicabili a tutti i progetti., Ecco perché troverai toni di “Dimentica CSSLint, è supponente e non si adatta al tuo progetto” commenti e molti altri simili su Internet.

Puoi trovare alcuni pezzi di codice che sono chiamati Linters per qualche motivo, ma almeno ti dicono “Sono un formattatore di codice supponente” come questo .,

HTML panno potrebbe essere utile, a volte, come forza di aggiungere un attributo ” alt ” per le immagini e di accessibilità e di buone pratiche (Ide mostra un messaggio di avviso per troppo senza l’aggiunta di un panno, che è meglio) ma questo non impedisce di utilizzare un <campo> come <p> o altri errori di html o di utilizzo.

Ti infastidirà anche se stai scrivendo componenti di template con affermazioni stupide come “non hai una dichiarazione doctype, non hai html, head, title o body tag., E potresti “ovviamente, dato che questo file verrà caricato all’interno di un documento che ha già questi tag” ma HTML lint non può saperlo; I lint sono pedine statiche e stai lavorando su un ambiente dinamico, quindi vai avanti ed elimina html lint.

CSSLint è un po ‘ diverso, non c’è niente che puoi lint qui comunque, puoi scrivere CSS validi o non validi ma questo è tutto.,

Ci sono buone pratiche sui CSS che stanno per scopi di efficienza e velocità (beneficeranno anche di UX), altre che andranno per scopi di manutenibilità, scalabilità e leggibilità (di solito basate sull’esperienza di sviluppo), altre per accessibilità (basate su studi UI/UX e rendering del browser, test di contrasto dello schermo e così). Ma non ha senso combinare tutto in un linter e dire agli sviluppatori di abbinare tutte quelle pratiche, prima di tutto perché ci sono contraddizioni che hanno bisogno di un essere umano per prendere la decisione di usare l’una o l’altra.,

Un caso d’uso in cui scegliere potrebbe essere affrontato dal fatto che l’aggiunta di tutto il codice CSS di accessibilità aumenterà in modo osservabile le dimensioni, il tempo di caricamento e le metriche interattive per la prima volta, quindi di solito sceglierai solo le regole di accessibilità che si adattano meglio ai tuoi clienti mantenendo buone prestazioni.

Per impostare un esempio sciocco su una regola supponente sul CSSLint diciamo che voglio un gradiente lineare come sfondo sul blocco principale della mia homepage. CSSLint lancerà un avviso sulle prestazioni del gradiente lineare.,
A questo punto CSSLint vuole eliminare il gradiente lineare, ma quali sono le alternative?
Utilizzando un’immagine sarà toni di volte meno efficiente per raggiungere il disegno di destinazione (e ridurrà anche la qualità visiva del gradiente, e renderà più difficile ridimensionare per adattarsi a tutte le dimensioni posible del blocco).
Allora, cosa possiamo fare? Basta ignorare CSSLint, perché è supponente e questo non è supportato da alcun motivo.
C’è una differenza nell’aggiungere un gradiente lineare rispetto all’aggiunta di 42342 gradienti lineari sulla stessa vista., A proposito, se ne hai bisogno, sarà comunque più efficiente dell’utilizzo delle immagini.

Puoi anche trovare dichiarazioni contraddittorie su di esso come:

“Non usare ID per lo styling”. Il motivo è che sarà una regola non riutilizzabile.
e
“Non usare classi adiacenti”. Non sono riuscito a capire correttamente il motivo senza leggere la spiegazione delle regole css lint e il motivo è “Mentre tecnicamente consentito in CSS, questi non sono gestiti correttamente da Internet Explorer 6 e versioni precedenti”.

Ho qualcosa da dirti CSSLint., A nessuno importa di IE 6 e precedenti, siamo nel 2020, il 99% del software web supporta I. E. 11 tanto, che è stato rilasciato su 2013 a proposito e ha meno di un 3% di utilizzo.

D’altra parte, dove per l’amor di Dio si esprime che tutte le regole CSS devono essere riutilizzabili sulla stessa vista?
Se hai un oggetto unico sulla tua app web, cioè probabilmente hai solo una barra di navigazione, solo un popup di chat se presente, solo un logo della barra di navigazione e solo un piè di pagina per nominarne alcuni, perché devi aggiungere il suo stile globale? Non è una pratica così cattiva che è contraria a tutte le altre lingue del mondo?,

Come aggiunta, supponiamo che tu abbia 5 visualizzazioni sul tuo progetto. Se hai un <nav> sarà probabilmente mostrato su tutti, quindi lo stesso stile che hai messo sotto #primary-navigation sta lavorando su 5 viste diverse. Non è un modo di riutilizzabilità?

Per aumentare la stupidità attorno a entrambe le regole insieme, vedi come ti consente di affrontare una situazione difficile.,

Se non è possibile utilizzare un id per lo styling <nav class="dark-theme">, e non è possibile aggiungere adiacente classi<nav class="primary-navigation dark-theme">, come si sarà in grado di ambito il tuo stile rendendolo più gestibile, leggibile e come si fa a gestire per aggiungere java-script ascoltatori, quando necessario, in modo efficiente?

Semplicemente non puoi.

Cosa potremmo fare semanticamente corretto e facile da mantenere?, Facciamo un esempio:

Ecco un’altra affermazione che mi fa ridere per un po’:

Evita i selettori di attributi non qualificati “I selettori di attributi non qualificati, ad esempio , corrispondono prima a tutti gli elementi e quindi controllano i loro attributi. Ciò significa che i selettori di attributi non qualificati hanno le stesse caratteristiche prestazionali del selettore universale ( * ) ”

Mia cara, questo non è diverso da ciò che accade quando si utilizza class, id o tag selector.

Le fasi del rendering CSS del browser sono:

  1. Costruire il DOM., Il DOM è una struttura dati ad albero contenente tutti i nodi HTML della pagina. Ogni nodo contiene i dati relativi a quell’elemento HTML (come attributi, ID e classi) Se il nodo ha elementi HTML come figli, punterà anche a quei nodi figlio.
  2. Costruire il CSSOM. Quando il browser incontra un foglio di stile CSS (incorporato o esterno), deve analizzare il testo in qualcosa che può utilizzare per i layout di stile e le vernici. La struttura dati che il browser trasforma CSS in è creativamente chiamato CSSOM.
  3. Generazione di un albero di rendering., In breve, l’albero di rendering contiene tutte le informazioni necessarie al browser per creare pixel sulla pagina. Il browser fondamentalmente prende il DOM e CSSOM e li schiaccia insieme, rimuovendo tutto ciò che non avrà un effetto sull’output renderizzato.
  4. Layout e pittura.
  5. nella fase di layout, il browser calcola la dimensione e la posizione degli elementi (non ancora renderizzati) e poi, nella fase di paint, inizia a generare pixel che visualizzeremo.,

Come si può vedere si potrebbe ottenere un po ‘ di performance bias durante la nidificazione indiscriminatamente il selettori, come body>#main-content>.first-block .products-card p come si generano inutili nodi figlio in CSSOM che dovrà corrispondere a DOM e questo richiederà un po ‘ più di tempo rispetto all’utilizzo semplicemente un
.products-card p, ma come abbiamo bisogno di mantenere questo codice e, probabilmente, scala, dobbiamo campo di applicazione le norme quindi diciamo #main-content .products-card p.

È una buona pratica, ma non ho mai visto un’app Web in cui selettori più specifici stanno causando un collo di bottiglia della velocità di carico., Questo di solito è causato dall’iterazione più e più volte mantenendo i toni del codice inutilizzato che il browser aggiungerà a CSSOM e dovrà essere confrontato con DOM per capire se è ok aggiungerlo nell’albero di rendering o meno.

Per questo e altri molti motivi è per questo che puoi trovare articoli che spiegano ogni punto sbagliato su CSSLint come questo che spiega le cose in un modo più esteso di quello che ho fatto qui.

Sommario

Linters sono buoni per alcune cose e male per gli altri.,
Possono anche essere modificati per adattarsi ad alcune esigenze del progetto o ad alcune preferenze aziendali o personali per evitare queste regole che sono supponenti e aggiungere altre regole preziose che si adattano al progetto in cui ti trovi.

Ci sono molte ragioni per usare linter su linguaggi interpretati (su quelli compilati, l’IDE e il compilatore si occuperanno di questo, ma puoi anche aggiungere un Lint per controllare solo la formattazione del codice o per ricevere avvisi prima della compilazione per evitare di aspettare che il compilatore trovi un errore o finisca per sapere se è tutto OK).,

Ci sono pochi motivi per aggiungere linter in HTML (penso che solo gli scopi di accessibilità possano essere utili) e ci sono meno motivi per aggiungere linter su CSS (che possono essere ridotti a un codice un correttore di formattazione).

Hai usato una lanugine? Se è così, dicci in quale lingua e contesto e qual è stata la tua esperienza.

Personalmente mi è piaciuto dopo alcune modifiche quando si utilizza dattiloscritto.

Come sempre, spero che ti piaccia questo post e cordiali saluti,

Joel

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *