Sass Style Guide: un tutorial Sass su come scrivere un codice CSS migliore

Scrivere CSS coerenti e leggibili che si adattano bene è un processo impegnativo. Soprattutto quando i fogli di stile stanno diventando più grandi, più complessi e più difficili da mantenere. Uno degli strumenti a disposizione degli sviluppatori per scrivere CSS migliori sono i preprocessori. Un preprocessore è un programma che prende un tipo di dati e lo converte in un altro tipo di dati, e nel nostro caso i preprocessori CSS sono linguaggi di preelaborazione che vengono compilati in CSS. Esistono molti preprocessori CSS che gli sviluppatori front-end consigliano e utilizzano, ma in questo articolo ci concentreremo su Sass. Vediamo cosa ha da offrire Sass, perché è una scelta preferibile rispetto ad altri preprocessori CSS e come iniziare a usarlo nel migliore dei modi.

Cos'è Sass e perché dovresti usarlo?

Per chi non sapesse cosa sia il Sass, il miglior punto di partenza è visitare la pagina web ufficiale del Sass. Sass è l'acronimo di Syntactically Awesome StyleSheets ed è un'estensione di CSS che aggiunge potenza ed eleganza al linguaggio di base.

Sass è un preprocessore CSS con molte potenti funzionalità. Le caratteristiche più importanti sono variabili, estensioni e mixin.

Le variabili memorizzano informazioni che possono essere riutilizzate in seguito, come i colori o altri valori di uso comune. Le estensioni ti aiutano a creare "classi" che consentono l'ereditarietà delle regole. Mixin, puoi pensare a come "funzione". Sass ha anche altre caratteristiche sorprendenti rispetto ad altri preprocessori, come l'uso di istruzioni logiche (condizionali e loop), funzioni personalizzate, integrazione con altre librerie come Compas e molti altri. Queste funzionalità da sole possono aiutare te e il tuo team a essere più produttivi e a scrivere CSS migliori alla fine.

Perché hai bisogno di una guida di stile CSS

Sfortunatamente, anche i preprocessori non possono riparare tutto e aiutarti a scrivere un buon codice CSS. Il problema che ogni sviluppatore deve affrontare è che le attuali applicazioni web stanno diventando sempre più grandi. Ecco perché il codice deve essere scalabile e leggibile e deve evitare il codice spaghetti e le sue righe inutilizzate. Per evitare i problemi menzionati, è necessaria una sorta di standard per il tuo team nel lavoro quotidiano. Cos'è il codice spaghetti e come succede? Il codice spaghetti è un nome per codice cattivo, lento, ripetitivo e illeggibile. Quando un team scrive grandi applicazioni senza linee guida o standard definiti, ogni sviluppatore scrive ciò di cui ha bisogno e come vuole. Inoltre, quando gli sviluppatori scrivono molte correzioni di bug, hotfix e patch, tendono a scrivere codice che risolverà il problema ma non hanno il tempo di scrivere il codice nel modo migliore. In queste situazioni, è molto normale ritrovarsi con molte righe di CSS che non vengono più utilizzate in nessun settore dell'applicazione. Gli sviluppatori non hanno abbastanza tempo per pulire il codice e sono costretti a pubblicare la correzione il più rapidamente possibile. Un'altra situazione ricorrente è che per riparare rapidamente le cose rotte, gli sviluppatori usano molto !important , il che si traduce con un codice molto hacky che è difficile da mantenere, risulta con comportamenti molto inaspettati e deve essere rifattorizzato in seguito. Come già accennato, man mano che il codice cresce, la situazione peggiora.

L'idea di questo articolo è condividere regole, suggerimenti e best practices per scrivere un Sass migliore. Il raggruppamento di questi suggerimenti e best practice Sass può essere utilizzato come guida di stile Sass. Questa guida di stile dovrebbe aiutare gli sviluppatori a evitare le situazioni sopra menzionate. Le regole sono raggruppate in segmenti logici per un più facile riferimento, ma alla fine dovresti adottarle e seguirle tutte. O almeno, la maggior parte di loro.

Guida di stile

L'insieme delle regole e delle migliori pratiche in questa guida di stile sono adottate in base all'esperienza di lavoro con molti team. Alcuni provengono da tentativi per errore e altri sono ispirati da alcuni approcci popolari come BEM. Per alcune regole non esiste un motivo specifico per cui e come sono state stabilite. A volte basta avere l'esperienza passata come unica ragione. Ad esempio, per assicurarsi che il codice sia leggibile è importante che tutti gli sviluppatori scrivano il codice allo stesso modo, quindi c'è la regola per non includere spazi tra parentesi. Possiamo discutere se sia meglio includere lo spazio tra parentesi o meno. Se pensi che abbia un aspetto migliore quando ci sono spazi tra parentesi, regola questa guida di stile e le regole in base alle tue preferenze. Alla fine, l'obiettivo principale della guida di stile è definire le regole e rendere il processo di sviluppo più standard.

Regole generali CSS

Le regole generali dovrebbero essere sempre seguite. Si concentrano principalmente su come formattare il codice Sass per portare coerenza e leggibilità del codice:

• Per il rientro, usa gli spazi invece delle tabulazioni. La migliore pratica consiste nell'utilizzare 2 spazi. Puoi eseguire la tua guerra sacra con questa opzione e puoi definire la tua regola e utilizzare schede o spazi o qualsiasi cosa ti si addice meglio. È importante solo definire una regola e seguirla pur essendo coerenti.
• Includere una riga vuota tra ogni istruzione. Questo rende il codice più leggibile dall'uomo e il codice è scritto dagli umani, giusto?
• Utilizzare un selettore per riga, in questo modo:

 selector1, selector2 { }

• Non includere uno spazio tra parentesi.

 selector { @include mixin1($size: 4, $color: red); }

• Usa virgolette singole per racchiudere stringhe e URL:

 selector { font-family: 'Roboto', serif; }

• Termina tutte le regole con un punto e virgola senza spazi prima di:

 selector { margin: 10px; }

Regole per i selettori

Successivamente stiamo seguendo una serie di regole da utilizzare quando si ha a che fare con i selettori:

• Evitare l'uso di selettori ID. Gli ID sono troppo specifici e utilizzati principalmente per le azioni JavaScript.
• Evita !important . Se devi usare questa regola, significa che qualcosa non va con le tue regole CSS in generale e che il tuo CSS non è strutturato bene. CSS con molte regole !important può essere facilmente abusato e finisce con un codice CSS disordinato e difficile da mantenere.
• Non utilizzare il selettore figlio. Questa regola condivide lo stesso ragionamento di quella ID. I selettori figlio sono troppo specifici e sono strettamente associati alla struttura HTML.

Mantieni le tue regole Sass in ordine

È importante mantenere la coerenza nel codice. Una delle regole è che è necessario mantenere l'ordine delle regole. In questo modo altri sviluppatori possono leggere il codice con molta più comprensione e trascorreranno meno tempo a orientarsi. Ecco l'ordine proposto:

1. Usa prima @extend . Questo ti fa sapere all'inizio che questa classe eredita regole da altrove.
2. Usa @include successivo. Avere i tuoi mixin e funzioni inclusi nella parte superiore è bello da avere e ti consente anche di sapere cosa sovrascriverai (se necessario).
3. Ora puoi scrivere la tua normale classe CSS o le regole degli elementi.
4. Posiziona pseudo classi e pseudo elementi nidificati prima di qualsiasi altro elemento.
5. Infine, scrivi altri selettori nidificati come nell'esempio seguente:

 .homepage { @extend page; @include border-radius(5px); margin-left: 5px; &:after{ content: ''; } a { } ul { } }

Alcune convenzioni di denominazione

Convenzioni di denominazione parte del libro di stile si basa sulle due convenzioni di denominazione BEM e SMACSS esistenti che sono diventate popolari tra gli sviluppatori. BEM sta per Blocco, Elemento, Modificatore. È stato sviluppato dal team YANDEX e l'idea alla base di BEM era quella di aiutare gli sviluppatori a comprendere la relazione tra HTML e CSS nel progetto. SMACSS d'altra parte sta per Scalable and Modular Architecture for CSS. È una guida per strutturare i CSS per consentire la manutenibilità.

Ispirandosi a loro, le nostre regole per le convenzioni di denominazione sono le seguenti:

• Usa il prefisso per ogni tipo di elemento. Prefissa i tuoi blocchi, come: layout ( l- ), moduli ( m- ) e stati ( is- ).
• Usa due caratteri di sottolineatura per gli elementi figlio per ogni blocco:

 .m-tab__icon {}

• Usa due trattini per i modificatori per ogni blocco:

 .m-tab--borderless {}

Variabili

Usa variabili. Inizia con le variabili più generali e globali come i colori e crea un file separato per loro _colors.scss . Se noti che stai ripetendo più volte un valore sul foglio di stile, vai e crea una nuova variabile per quel valore. Si prega di ASCIUGARE. Sarai grato quando vorrai cambiare quel valore e quando dovrai cambiarlo in un solo posto.

Inoltre, usa un trattino per nominare le tue variabili:

 $red : #f44336; $secondary-red :#ebccd1;

Query sui media

Con Sass puoi scrivere le tue media query come query element. La maggior parte degli sviluppatori scrive le query multimediali in un file separato o in fondo alle nostre regole, ma non è consigliabile. Con Sass puoi scrivere cose come il seguente esempio annidando le media query:

 // ScSS .m-block { &:after { @include breakpoint(tablet){ content: ''; width: 100%; } } }

Questo genera un CSS come questo:

 // Generated CSS @media screen and (min-width: 767px) { .m-block:after { content: ''; width: 100%; } }

Queste regole per le query multimediali nidificate ti consentono di sapere molto chiaramente quali regole stai sovrascrivendo, come puoi vedere nello snippet Sass in cui vengono utilizzate le query multimediali con nome.

Per creare query multimediali con nome, crea il tuo mixin in questo modo:

 @mixin breakpoint($point) { @if $point == tablet { @media (min-width: 768px) and (max-width: 1024px) { @content; } } @else if $point == phone { @media (max-width: 767px) { @content; } } @else if $point == desktop { @media (min-width: 1025px) { @content; } } }

Puoi leggere di più sulla denominazione delle media query nei seguenti articoli: Denominazione di media query e Scrivi migliori media query con Sass.

altre considerazioni

Alla fine, ecco alcune altre considerazioni che dovresti anche tenere a mente e seguire:

• Non scrivere mai i prefissi dei fornitori. Usa invece il prefisso automatico.
• Utilizza al massimo tre livelli di regole nidificate in profondità. Con più di tre livelli nidificati, il codice sarà difficile da leggere e forse stai scrivendo un selettore scadente. Alla fine, stai scrivendo codice CSS da abbinare al tuo HTML.

 .class1 { .class2 { li { //last rules } } }

• Non scrivere più di 50 righe di codice nidificato: o meglio, non scrivere più di X righe di codice nidificato. Imposta la tua X, ma 50 sembra un buon limite. Se superi quel limite, forse il blocco di codice non si adatta alla finestra dell'editor di testo.
• Scrivi un file principale in cui importerai tutti i tuoi blocchi, parziali e configurazioni.
• Importa prima il fornitore e le dipendenze globali, quindi le dipendenze create, quindi i layout, i modelli e infine le parti e i blocchi. Questo è importante per evitare importazioni miste e sovrascrittura di regole, perché il fornitore e le regole globali non possono essere gestite da noi.
• Non essere timido e rompi il tuo codice in quanti più file possibile.

Conclusione

L'idea alla base di questa guida di stile è di darti alcuni consigli su come migliorare il modo in cui stai scrivendo il tuo codice Sass. Tieni presente che anche se non stai utilizzando Sass, i suggerimenti e le regole forniti in questa guida di stile sono applicabili e si consiglia di seguire anche se utilizzi Vanilla CSS o un altro preprocessore. Di nuovo, se non sei d'accordo con nessuna delle regole, cambia la regola per adattarla al tuo modo di pensare. Alla fine, sta a te e al tuo team adattare questa guida di stile, utilizzare un'altra guida di stile o crearne una completamente nuova. Basta definire la guida e iniziare a scrivere un codice fantastico.