Come ottimizzare i CSS con le guide di stile del codice

Quando i designer parlano di guide di stile, in genere intendono un manuale concordato sul aspetto coerente di un sito Web o un'applicazione, con un design ben progettato combinazione di colori, tipografia e interfaccia utente è usato in tutto il progetto.

C'è anche un altro tipo di guida allo stile che possiamo usare nello sviluppo web, ed è altrettanto importante ma molto più raramente discusso: guide di stile per il codice stesso. Le guide di stile del codice sono piuttosto per gli sviluppatori che per i progettisti e il loro obiettivo principale è quello di ottimizzare CSS o altro codice.

Mettere in atto le guide di stile del codice appropriate ci fornisce a una base di codice più organizzata e coerente, una migliore leggibilità del codice e un codice più gestibile. Non è una coincidenza che le grandi compagnie tecnologiche, come Google, AirBnB o Dropbox facciano buon uso di esse.

In questo post daremo un'occhiata a come possiamo ottimizzare brillantemente il nostro CSS con l'aiuto delle guide di stile del codice CSS.

Code Style Guides vs. Pattern Libraries

Nel nostro settore c'è un certo grado di incertezza su ciò che possiamo chiamare una guida di stile. Un elenco a parte ad esempio, lo usa sinonimo del termine libreria di modelli in questo articolo, ma possiamo imbattersi in questo tipo di definizione anche in altri post.

D'altra parte, ci sono anche pubblicazioni, come CSS Tricks o il blog di Brad Frost, che distinguono le guide di stile del codice dalle librerie di modelli. Quest'ultimo approccio ci porta probabilmente ad avvicinarci a un sito web ottimizzato, come ci consente di gestire codice e design separatamente, quindi lo useremo in questo post.

Entrambe le guide di stile del codice e le librerie di modelli includono una strategia di stile, ma di un tipo diverso. Le librerie di pattern, come Bootstrap, Zurb Foundation, il Global Experience Language di BBC o la libreria di pattern di MailChimp, ci forniscono un'interfaccia utente con classi CSS premeditate, tipografia, combinazione di colori, a volte un sistema di griglia e altri schemi di progettazione.

Le guide di stile del codice CSS, come Evernote o ThinkUp (o quelle menzionate nell'introduzione) contengono regole su come scrivere CSS comprese cose come convenzioni di denominazione, struttura dei file, ordine delle proprietà, formattazione del codice, e altri.

Nota che i generatori di guide di stile vivente, come KSS, Styledown o Pattern Lab, generare librerie di modelli e non guide di stile di codifica. Anche se le librerie di pattern sono anche molto utili e migliorano il processo di sviluppo web, non ci permettono di ottimizzare il codice stesso.

Crea la tua guida allo stile del codice CSS

L'obiettivo finale di una guida allo stile del codice CSS è garantire che possiamo lavorare con una base di codice coerente, facilmente intercambiabile, scritta da sviluppatori che seguono tutte le stesse regole di stile del codice. La creazione di una guida allo stile del codice CSS può richiedere un po 'di tempo, ma ne vale la pena, dato che dobbiamo farlo una sola volta. Quindi possiamo usare la stessa guida di stile su diversi progetti.

È importante notare che le migliori guide di stile non solo contengono le regole di stile, ma anche esempi di uso buono e cattivo, in questo modo gli sviluppatori possono comprendere in modo più intuitivo le regole.

Ad esempio AirBnB mostra agli sviluppatori buoni e cattivi esempi nel seguente modo facilmente digeribile:

Struttura del file

Innanzitutto, dobbiamo capire una logica in base alla quale organizzeremo i nostri file CSS. Per i progetti più piccoli un file CSS può essere sufficiente, ma per quelli più grandi è sempre meglio suddividere il codice, e concatena i file separati successivamente in produzione.

Anche alcune guide di stile come ThinkUp's ci mettono in guardia non usare stili incorporati o incorporati a meno che non sia inevitabile; è anche una regola utile che vale la pena applicare.

annidamento

L'annidamento è una funzionalità eccezionale nei CSS, ma a volte può andare fuori controllo. Nessuno si sente particolarmente felice, soprattutto nel bel mezzo di un processo di debugging frustrante, imbattendosi in selettori extra lunghi come questo:

 .class_1 .class_2 # id_1 # id_2 li a span color: #bad; 

Quindi va sempre bene impostare un ragionevole limite di annidamento, per esempio GitHub ha scelto tre livelli nella sua guida di stile. Limitando il nidificazione possiamo anche costringerci a scrivere un codice meglio strutturato.

Regole di denominazione

L'utilizzo di regole di denominazione coerenti per i selettori CSS è fondamentale se vogliamo comprendere il nostro codice mesi o anche anni dopo. Ci sono molte soluzioni là fuori, e c'è solo una regola severa che dobbiamo seguire ad esempio un nome di selettore non può iniziare con un numero.

I quattro stili comuni utilizzati nella denominazione del selettore sono .minuscolo, .under_scores, .dash-es, e .lowerCamelCase. Va bene scegliere uno di essi, ma dobbiamo seguire la stessa logica per l'intero progetto.

utilizzando solo nomi di selettori semantici è anche essenziale se vogliamo avere un codice significativo. Ad esempio, invece di .del pulsante rosso (che non mostra cosa fa il pulsante) è meglio usare il .avviso pulsante nome (che dice quello che fa), in questo modo, permettiamo agli sviluppatori (e ai nostri sé futuri) di capire cosa fa il pulsante.

inoltre se vogliamo cambiare il suo colore da rosso a qualcos'altro in futuro, possiamo facilmente farlo senza problemi. Esistono anche convenzioni di denominazione CSS predefinite, come la convenzione BEM (Block, Element, Modifier) portare a una struttura di denominazione coerente con nomi unici e significativi.

Regole di formattazione

La formattazione del codice include cose come l'uso di spazi bianchi, tabulazioni, indentazione, spaziatura, interruzioni di riga, ecc. Non c'è davvero un metodo universalmente buono o cattivo nella formattazione, l'unica regola è quella di scegli regole coerenti che risultino in un codice leggibile, e seguili attraverso.

Dropbox ad esempio richiede agli sviluppatori di inserire spazi dopo i due punti nelle dichiarazioni di proprietà, mentre Evernote utilizza due spazi per il rientro. Possiamo impostare tutte le regole di formattazione che ci piacciono, ma mai più di quanto sia possibile afferrare.

Ordine di dichiarazione

Le cose ordinate sono sempre più facili da vedere e ordinare le dichiarazioni CSS (proprietà con i loro valori) secondo una regola che ha senso, si traduce in un codice meglio organizzato.

Date un'occhiata ad esempio alle regole di ordinamento delle proprietà di WordPress, definisce la seguente linea di base semplice ma logica per l'ordine in cui le proprietà sono raggruppate in base al loro significato:

1. Display
2. Posizionamento
3. Box model
4. Colori e tipografia
5. Altro

Unità e valori

Decidere su come vogliamo usare unità e valori non è importante solo per ottenere un aspetto coerente del codice, ma anche se non lo facciamo, potremmo ritrovarci con qualcosa di strano

Immagina un sito che usa alternativamente px, em, e rem misure di lunghezza. Non sarà solo un brutto aspetto nell'editor di codice, ma molto probabilmente alcuni elementi saranno sorprendentemente piccoli o grandi su quel sito.

Abbiamo anche bisogno di prendere decisioni sui valori dei colori (esadecimali, rgb o hsl), e se vogliamo usare le proprietà abbreviate e in base a quali regole. C'è un'istruzione che è inclusa in ogni guida di stile del codice CSS in cui mi sono imbattuto, vale a dire. non specificare unità per valori 0 (davvero, solo non farlo).

.class // buon margine: 0; // bad margin: 0px; // margine errato: 0em; // cattivo margine: 0rem; 

Commentando

Il codice di commento è essenziale in tutte le lingue, ma in CSS non solo facilita il debugging e la creazione di documentazione, ma anche sezioni di regole CSS in gruppi logici. Possiamo usare entrambi / * ... * / o il // ... stile di notazione per i commenti in CSS, l'importante è farlo rimanere coerenti con commenti in tutto il nostro progetto.

I CSS idiomatici, ad esempio, stabiliscono un sistema di commento significativo che utilizza anche un'arte ASCII di base e produce un codice ben organizzato: