Ottenere il nostro codice revisionato da un professionista è un ottimo modo per migliorare la qualità del codice, ma cosa succede se non si ha accesso a un programmatore rockstar? Fai la cosa migliore e prendi un po 'di lanugine per quella lingua.
Oggi vorrei parlare un po 'di CSSLint, uno strumento di analisi del codice rilasciato di recente, avete indovinato, CSS. Unisciti a me dopo il salto!
Colpire Wikipedia per una definizione:
Lint è uno strumento che contrassegna l'utilizzo sospetto nel software scritto in qualsiasi linguaggio del computer.
Fondamentalmente, un filaccia guarda il nostro codice e controlla le cattive pratiche di programmazione. Variabili indefinite, costrutti inefficienti, cose del genere.
Probabilmente ti starai chiedendo perché mai avrai bisogno di uno strumento del genere. Ammettiamolo: non tutti noi possediamo la conoscenza suprema di ciò con cui stiamo lavorando o abbiamo il lusso di far revisionare il nostro codice peer. In questi casi, applicare il nostro codice in un lint è la prossima opzione migliore. E a differenza degli strumenti di ripulitura, la lanuginatura sputa alcune informazioni sul tuo codice e su come migliorarlo.
Creato da Nicholas Zakas e Nicole Sullivan, CSSLint è uno strumento open source che controlla la sintassi di una serie di regole predefinite per eliminare le inefficienze possibili e assicurarsi che la presentazione funzioni come previsto con piccole sorprese.
Dopo aver visitato il sito CSSLint, puoi semplicemente incollare il codice sorgente CSS e scegliere le regole che desideri applicare. Premi il pulsante lint e CSSLint inizierà a erodere il tuo smugness.
Se sei un drogato di Node come me, c'è anche una versione per questo. Basta digitare sudo npm install -g csslint
e sei a posto!
Diamo una rapida occhiata alle regole che CSSLint applica.
Se sei come me, alcune regole devono averti sconcertato.
Francamente, sì, no e tutto il resto.
Dopo essermi annidato in una serie di forum di discussione e stanze IRC, ho scoperto che molti sviluppatori sembrano essere in subbuglio per le regole e forse proprio così. Lasciatemi tentare di spiegare perché la maggior parte delle regole ha senso, ma altre no.
Gli ID non dovrebbero essere usati nei selettori perché queste regole sono troppo strettamente accoppiate con l'HTML e non hanno possibilità di riutilizzo. È molto preferibile utilizzare le classi nei selettori e quindi applicare una classe a un elemento nella pagina.
Questo ha colpito molto con molti sviluppatori dato che siamo abbastanza abituati ad assegnare gli ID per i principali componenti strutturali di un layout come l'intestazione e il piè di pagina.
CSSLint sostiene che lo stile di tali elementi, per definizione, non può essere riutilizzato direttamente. Se vuoi una doppia barra laterale sulla tua pagina, una classe ti consente di riutilizzare lo stile mentre un ID no.
Tieni presente che solo perché una classe può essere riutilizzata non significa che debba essere. Classi uniche sono perfettamente accettabili e un modo perfetto per riutilizzare lo stile in caso di necessità.
Gli elementi di intestazione (h1-h6) dovrebbero essere definiti come stili di livello superiore e non ambiti per determinate aree della pagina.
La maggior parte degli sviluppatori, incluso me, si è abituata a scrivere intestazioni sensibili al contesto. Come in, definiamo uno stile separato per le intestazioni a seconda, per esempio, su quale pagina viene visualizzata. Un argomento a favore di questo approccio è che sposta tutto il cruft dal markup al foglio di stile. Si può semplicemente definire un tag e lasciare che il CSS a cascata di conseguenza.
CSSLint sostiene che un tale approccio compromette la prevedibilità del tuo progetto. Se qualcun altro dovesse riprendere il tuo progetto e provato a inserire un titolo da qualche parte, lui / lei avrebbe dovuto essere consapevole del contesto e del posizionamento dell'elemento. Con intestazioni definite incondizionatamente, lui o lei può usare un titolo ovunque sicuro della sua presentazione, indipendentemente dai suoi genitori.
Gli elementi di intestazione (h1-h6) dovrebbero avere esattamente una regola su un sito.
Un'estensione della regola di cui sopra per migliorare la prevedibilità della presentazione. Giusto o sbagliato, tieni presente che questo in pratica esclude l'inclusione di una sorta di codice di ripristino all'interno del foglio di stile. Ogni foglio di ripristino funziona anche sulle intestazioni e pertanto CSSLint lo contrassegnerà come un errore.
Le classi adiacenti sembrano come .foo.bar. Sebbene tecnicamente consentito nei CSS, questi non sono gestiti correttamente da Internet Explorer 6 e versioni precedenti.
Con questa regola abilitata, CSSLint contrassegna le regole come .nav.red
, con il motivo ufficiale che Internet Explorer 6 e versioni successive non funzionano bene con il selettore. Rispetto gli sviluppatori ma non sono d'accordo qui. Solo perché non funziona Internet "Dev-Buster" Explorer 6 non è un buon motivo per smettere di lavorare con una funzionalità utile.
I bordi e il riempimento aggiungono spazio al di fuori del contenuto di un elemento. Impostare la larghezza o l'altezza insieme ai bordi e al padding è di solito un errore perché non otterrai il risultato visivo che stai cercando. CSS Lint avvisa quando una regola usa larghezza o altezza oltre a padding e / o border.
Il modello di box potrebbe essere rotto, ma quasi tutti gli sviluppatori front-end che conosco sono intimamente consapevoli delle carenze e di come superare le disparità con l'implementazione. Siamo davvero pronti a rinunciare a un livello di controllo perché alcuni browser meno recenti hanno un'implementazione diversa?
L'utilizzo dei caratteri Web comporta implicazioni sulle prestazioni in quanto i file dei font possono essere piuttosto grandi e alcuni browser bloccano il rendering durante il loro download. Per questo motivo, CSS Lint ti avviserà quando ci sono più di cinque caratteri web in un foglio di stile.
Non prevedo una situazione in cui utilizzerei più di cinque caratteri in una pagina, ma ritengo che immergersi in questo territorio sia un po 'discutibile. Se mai, questo è un difetto di progettazione di un difetto di sviluppo. Se uno sviluppatore fa riferimento a cinque caratteri separati nel suo foglio di stile, è probabile che non sia un caso.
CSS Lint controlla semplicemente per vedere se hai usato float più di 10 volte e, in tal caso, visualizza un avviso. L'uso di questo numero di galleggianti di solito significa che è necessario un qualche tipo di astrazione per ottenere il layout.
Mentre concordo con l'argomento dei creatori che avere più di dieci istanze di float è una cattiva idea, sento anche che questo influenzerà il markup una volta passata una determinata dimensione.
Ad esempio, in una situazione in cui desideri rendere mobili due elementi, tradizionalmente utilizzi:
? e lo styling, con metodi tradizionali.
.contenitore-1 larghezza: 70%; fluttuare: a sinistra; .container-2 width: 30%; fluttuare: a sinistra;
Il metodo CSSLint dovrebbe astrarre il float in questo modo:
? e lo stile in questo modo:
.contenitore-1 larghezza: 70%; .container-2 width: 30%; .float float: left;
Mentre sono d'accordo sul fatto che questo è un approccio praticabile, sento che il markup diventerà molto affollato una volta che tenti di astrarre più cose. Preferirei vedere una classe che contiene la maggior parte del suo stile in un posto piuttosto che ingombrare il markup con 10+ classi. Di nuovo, sento che questo è un argomento soggettivo.
Tutte le regole sopra riportate rispettano le attuali pratiche standard. Certo, alcune regole hanno poco significato nel mondo reale, come valori zero che non richiedono unità, o saranno catturate da un IDE decente, come errori di parsing, ma tuttavia queste sono buone regole da avere in una suite di test CSS.
CSSLint aiuterà molti sviluppatori lungo la strada ma?
CSSLint è, senza dubbio, scritto da sviluppatori con grandi credenziali e sicuramente aiuterà moltissimi sviluppatori e designer lungo la strada.
Quello che trovo un po 'fastidioso è che molte delle regole controverse provengono da CSS orientato agli oggetti, un framework CSS destinato a consentire agli sviluppatori di scrivere CSS mantenibili. Anche se non ho nulla contro la struttura e il suo paradigma, dovresti essere d'accordo sul fatto che è un modo di fare le cose, no il modo di fare le cose.
Al contrario di JSLint, dove mi sembra che tutte le regole abbiano un senso, con CSSLint, sembra che mi venga detto che uno stile di scrittura CSS è giusto e che gli altri hanno torto. Sarebbe come se qualcuno mi chiedesse di rinunciare ai Beatles perché Rolling Stones è la loro band preferita.
Gli strumenti sono proprio questo: strumenti.
Certo, noi, come gruppo, tendiamo ad essere piuttosto appiccicosi quando si tratta del nostro codice. Non ci fa piacere sentire che il nostro codice potrebbe avere * ansimare * potenziali problemi o essere scritto in un modo completamente diverso.
La cosa principale da prendere in considerazione è che CSSLint è, in definitiva, uno strumento. Ti fa semplicemente sapere che alcune delle aree potrebbe avere errori.
CSSLint non deve essere il pugno di ferro attorno al quale si basa il tuo intero ego. Non c'è motivo di piegarsi all'indietro per evitare un avvertimento se sai esattamente cosa stai facendo.
sì.
Nei CSS, come nel calcolo integrale, ci sono molte soluzioni per un determinato problema. Non c'è necessariamente un modo "migliore" di fare le cose - si può favorire la leggibilità mentre io posso favorire l'efficienza. Ciò che è importante è che ti rendi conto che ognuno di noi ha il nostro modo unico di fare le cose.
Se non hai le stesse prospettive per risolvere un problema, potresti non essere d'accordo con un altro approccio e potresti persino trovarlo discutibile.
Detto questo, non c'è mai una buona ragione per non imparare cose nuove. Guardare i problemi dal punto di vista di un altro sviluppatore è un ottimo modo per vedere se puoi imparare qualcosa di nuovo.
Cosa ne pensi di CSSLint? Trovalo utile? Confondere? Ha aiutato con i tuoi problemi del mondo reale? Fateci sapere nei commenti.
Sii eccellente l'uno con l'altro e grazie mille per la lettura!