Sådan optimeres CSS med Code Style Guides

Når designere snakker om stilguider, betyder de normalt en aftalt manual på den sammenhængende udseende og følelse af et websted eller en ansøgning med en veldesignet farveskema, typografi og brugergrænseflade der bruges over hele projektet.

Der er en anden type stil guide, vi kan bruge i webudvikling, og det er lige så vigtigt, men meget mere sjældent diskuteret: stil guider til selve koden. Kode stil guider er snarere for udviklere end designere, og deres vigtigste mål er at optimere CSS eller anden kode.

At sætte rigtige kode stil guider i brug giver os en bedre organiseret, konsekvent kodebase, forbedret kode læsbarhed og mere vedligeholdelig kode. Det er ikke tilfældigt, at store tech-virksomheder, som Google, AirBnB eller Dropbox, gør brug af dem godt.

I dette indlæg vil vi se på, hvordan vi kan klare optimere vores CSS ved hjælp af CSS kode stil guides.

Kode Stil Guides vs Mønter Biblioteker

I vores branche er der en vis grad af usikkerhed om, hvad vi kan kalde en stilguide. En liste fra hinanden for eksempel bruger det synonymt med udtrykket mønster bibliotek i denne artikel, men vi kan også støde på denne slags definition i andre indlæg.

På den anden side er der også publikationer, som f.eks. CSS Tricks eller Brad Frosts blog, der skelner kodestyringsguider fra mønsterbiblioteker. Denne sidstnævnte tilgang tager os nok tættere på et veloptimeret websted, som det giver os mulighed for at håndtere kode og design separat, så vi vil bruge dette i dette indlæg.

Både kode stil guider og mønster biblioteker omfatter en styling strategi, men en anden art. Møntsbiblioteker, såsom Bootstrap, Zurb Foundation, BBC's Global Experience Language, eller MailChimp's mønsterbibliotek, giver os et brugergrænseflad med forudbyggede CSS-klasser, typografi, farveskema, nogle gange et gittersystem og andre mønstre.

CSS kode stil guider, såsom Evernote's eller ThinkUp's (eller dem nævnt i intro) indeholder regler om, hvordan man skriver CSS herunder ting som navngivningskonventioner, filstruktur, ejendomsordre, kodeformatering, og andre.

Bemærk at generatorer med levende stilstyring, som f.eks. KSS, Styledown eller Pattern Lab, generere mønsterbiblioteker og ikke kodning stil guider. Mens mønsterbiblioteker også er meget nyttige og hæver webudviklingsprocessen, tillader de os ikke at optimere selve koden.

Bygg din CSS Kode Style Guide

Det endelige mål for en CSS kode stil guide er at sikre, at vi kan arbejde med en konsistent, let debuggable kode base skrevet af udviklere, der alle følger de samme kode styling regler. Oprettelse af en CSS kode stil guide kan tage lidt tid, men det er værd at indsatsen, da vi kun skal gøre det en gang. Så kan vi bruge den samme stil guide på tværs af forskellige projekter.

Det er vigtigt at bemærke, at den bedste stil guider indeholder ikke kun stylingsreglerne selv, men også eksempler af god og dårlig brug, som på denne måde kan udviklere mere intuitivt forstå reglerne.

For eksempel viser AirBnB gode og dårlige eksempler til udviklere på følgende let fordøjelige måde:

Filstruktur

For det første skal vi finde ud af en logik, hvorefter vi vil organisere vores CSS-filer. For mindre projekter kan en CSS-fil være nok, men for større er det altid bedre at bryde op koden, og sammenkoble de separate filer senere i produktionen.

Nogle stilguider som ThinkUp's advarer os også om bruger ikke inline eller embedded styles medmindre det er uundgåeligt det er også en nyttig regel, der er værd at anvende.

nesting

Nesting er en stor funktion i CSS, men det kan til tider gå ud af kontrol. Ingen føler sig særligt glad, især midt i en frustrerende debugging-proces, der støder på ekstra lange selektorer som denne:

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

Så det er altid godt at oprette en rimelig nesting grænse, for eksempel valgte GitHub tre niveauer i sin stil guide. Ved at begrænse nesting kan vi også tvinge os til at skrive en bedre struktureret kode.

Navngivningsregler

Brug af sammenhængende navngivningsregler for CSS-selektorer er afgørende, hvis vi ønsker at forstå vores kode måneder eller endog år senere. Der er mange løsninger derude, og der er kun en streng regel, vi skal følge dvs. et vælgernavn kan ikke starte med et tal.

De fire almindelige stilarter, der anvendes i vælgernavnet, er .små bogstaver, .under_scores, .dash-es, og .lowerCamelCase. Det er okay at vælge nogen af ​​dem, men vi skal følge den samme logik på tværs af hele projektet.

Ved brug af Kun semantiske vælgernavne er også vigtigt, hvis vi vil har meningsfuld kode. For eksempel i stedet for .rød-knap (som ikke viser hvad knappen gør) er det bedre at bruge .alarm-knap navn (som siger hvad det gør), så gør vi det muligt for udviklere (og vores fremtidige selv) at forstå, hvad den nævnte knap gør.

i øvrigt hvis vi vil ændre sin farve fra rød til noget andet i fremtiden, kan vi nemt gøre det uden besvær. Der er også præmade CSS navngivningskonventioner, såsom BEM (Block, Element, Modifier) ​​konventionen, at resultere i en ensartet navngivningsstruktur med unikke og meningsfulde navne.

Formateringsregler

Kodeformatering omfatter ting som brugen af ​​hvide rum, faner, indrykning, mellemrum, linjeskift osv. Der er ikke rigtig en universel god eller dårlig metode til formatering. Den eneste tommelfingerregel er at Vælg sammenhængende regler, der resulterer i en læsbar kode, og følg dem igennem.

Dropbox kræver for eksempel udviklere at placere mellemrum efter tyktarmen i ejendomserklæringer, mens Evernote bruger to mellemrum til indrykning. Vi kan konfigurere så mange formateringsregler som vi er fortrolige med, men aldrig mere end det er muligt at forstå.

Erklæring Ordre

Ordnede ting er altid nemmere at se igennem, og bestilling af CSS-erklæringer (egenskaber med deres værdier) ifølge en regel, der giver mening i en bedre organiseret kode.

Se f.eks. På WordPresss ejendomsbestemmelsesregler, den definerer følgende enkle men logiske basislinje for bestilling, hvor ejendomme er grupperet efter deres betydning:

1. Skærm
2. Positionering
3. Box model
4. Farver og typografi
5. Andet

Enheder og værdier

At beslutte, hvordan vi vil bruge enheder og værdier, er ikke kun vigtigt for at opnå et ensartet kodeudseende, men også hvis vi ikke gør det, kan vi ende med noget mærkeligt

Forestil dig et websted, der skiftevis bruger px, em, og rem længde målinger. Det vil ikke kun se dårlig ud i kodeditoren, men sandsynligvis vil nogle elementer være overraskende små eller store på det pågældende websted.

Vi skal også træffe beslutninger om farveværdier (hexadecimal, rgb eller hsl), og om vi vil bruge stenografiegenskaber og i henhold til hvilke regler. Der er en instruktion, der er inkluderet i hver CSS kode stil guide jeg støde på, dvs.. angiv ikke enheder for 0 værdier (virkelig bare ikke).

.klasse // god margin: 0; // dårlig margin: 0px; // dårlig margin: 0em; // dårlig margin: 0rem; 

I en kommentar

Kommentarskode er afgørende på alle sprog, men i CSS det lader ikke kun debugging og dokumentation gøre, men også sektioner CSS regler i logiske grupper. Vi kan bruge enten / * ... * / eller den // ... notation stil til kommentarer i CSS, det vigtige er at forbliv konsekvent med kommentarer gennem hele vores projekt.

Idiomatic CSS etablerer for eksempel et meningsfuldt kommentarsystem, som endda bruger nogle grundlæggende ASCII-kunst og resulterer i smukt organiseret kode: