Slik optimaliserer du CSS med kodestiler

Når designere snakker om stilguider, betyr de vanligvis en avtalt håndbok på sammenhengende utseende og følelse av et nettsted eller et søknad, med en godt utformet fargevalg, typografi og brukergrensesnitt som brukes over hele prosjektet.

Det er en annen type stilguide vi kan bruke i webutvikling også, og det er like viktig, men mye mer sjelden diskutert: stil guider for selve koden. Kode stil guider er heller for utviklere enn designere, og deres hovedmål er å optimalisere CSS eller annen kode.

Å sette riktige kode stil guider i bruk gir oss en bedre organisert, konsistent kodebase, forbedret kodelesbarhet og mer vedlikeholdsbar kode. Det er ikke et tilfeldighet at store tech-selskaper, som Google, AirBnB eller Dropbox, gir god bruk av dem.

I dette innlegget vil vi se på hvordan vi kan smartt optimalisere CSS ved hjelp av CSS kode stil guider.

Kode Stilguider vs Mønsterbiblioteker

I vår bransje er det en viss grad av usikkerhet om hva vi kan kalle en stilguide. En liste fra hverandre for eksempel bruker det synonymt med begrepet mønsterbibliotek i denne artikkelen, men vi kan støte på denne typen definisjon i andre innlegg også.

På den annen side er det også publikasjoner, som for eksempel CSS Tricks eller Brad Frosts blogg, som skiller kodestilguider fra mønsterbiblioteker. Denne siste tilnærmingen tar sannsynligvis oss nærmere et godt optimalisert nettsted, som det tillater oss å håndtere kode og design separat, så vi vil bruke dette i dette innlegget.

Både kodestyring og mønsterbiblioteker inkluderer en stylingstrategi, men en annen type. Mønsterbiblioteker, som Bootstrap, Zurb Foundation, BBCs Global Experience Language, eller MailChimps mønsterbibliotek, gir oss et brukergrensesnitt med forhåndsdefinerte CSS-klasser, typografi, fargevalg, noen ganger et rutenett og andre designmønstre.

CSS kode stil guider, for eksempel Evernote eller ThinkUp (eller de som er nevnt i intro) inneholder regler om hvordan man skriver CSS inkludert ting som navnekonvensjoner, filstruktur, eiendomsordre, kodeformatering, og andre.

Legg merke til at generatorer for levende stilstyring, for eksempel KSS, Styledown eller Pattern Lab, generere mønsterbiblioteker og ikke koding stil guider. Mens mønsterbiblioteker er også svært nyttige og hever webutviklingsprosessen, tillater de ikke oss å optimalisere koden selv.

Bygg din CSS Code Style Guide

Det endelige målet med en CSS-kodestilguide er å sikre at vi kan jobbe med en konsistent, lett debuggbar kodebase skrevet av utviklere som alle følger de samme kodestyringsreglene. Å lage en CSS kode stil guide kan ta litt tid, men det er verdt innsatsen, siden vi bare trenger å gjøre det en gang. Så kan vi bruke den samme stilguiden på tvers av ulike prosjekter.

Det er viktig å merke seg at den beste stilen guider inneholder ikke bare stylingsreglene selv, men også eksempler av god og dårlig bruk, slik at utviklere kan mer intuitivt forstå reglene.

For eksempel viser AirBnB gode og dårlige eksempler til utviklere på følgende lett fordøyelig måte:

Filstruktur

Først må vi finne ut en logikk som vi skal organisere våre CSS-filer til. For mindre prosjekter kan en CSS-fil være nok, men for større er det alltid bedre å bryte opp koden, og sammenkoble de separate filene senere i produksjonen.

Noen stilguider som ThinkUps, advarer oss også om bruker ikke inline eller innebygde stiler med mindre det er uunngåelig; Det er også en nyttig regel som er verdt å søke.

nesting

Nesting er en flott funksjon i CSS, men til tider kan det gå ut av kontroll. Ingen føler seg spesielt glad, spesielt i midten av en frustrerende feilsøkingsprosess, og støter på ekstra lange selektorer som dette:

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

Så det er alltid godt å sette opp en rimelig nesting grense, for eksempel valgte GitHub tre nivåer i sin stilguide. Ved å begrense nesting kan vi også tvinge oss til å skrive en bedre strukturert kode.

Navngivningsregler

Å bruke sammenhengende navngivningsregler for CSS-valg er avgjørende hvis vi ønsker å forstå våre kodemåneder eller år senere. Det er mange løsninger der ute, og Det er bare en streng regel vi må følge dvs. et seleksjonsnavn kan ikke starte med et tall.

De fire vanlige stilene som brukes i velgerenavn er .små bokstaver, .under_scores, .dash-es, og .lowerCamelCase. Det er greit å velge noen av dem, men vi må følge samme logikk over hele prosjektet.

Ved hjelp av bare semantiske velgerenavn er også viktig hvis vi vil har meningsfull kode. For eksempel, i stedet for .rød-knapp (som ikke viser hva knappen gjør) er det bedre å bruke .alert-knappen navn (som sier hva det gjør), slik at vi gjør det mulig for utviklere (og vår fremtidige selv) å forstå hva det er sagt.

Dess hvis vi ønsker å endre fargen fra rød til noe annet i fremtiden, kan vi enkelt gjøre det uten å måtte ha det. Det er også premade CSS navnekonvensjoner, som BEM (Block, Element, Modifier) ​​konvensjonen, som resultere i en konsekvent navngivningsstruktur med unike og meningsfulle navn.

Formateringsregler

Kodeformatering inkluderer ting som bruk av mellomrom, faner, innrykk, mellomrom, linjeskift osv. Det er egentlig ikke en universell god eller dårlig metode i formatering, den eneste tommelfingerregelen er å velg sammenhengende regler som resulterer i en lesbar kode, og følg dem gjennom.

Dropbox krever for eksempel utviklere å sette mellomrom etter kolon i eiendomserklæringer, mens Evernote bruker to mellomrom for innrykk. Vi kan sette opp så mange formateringsregler som vi er komfortable med, men aldri mer enn det er mulig å forstå.

Deklarasjonsordre

Bestilte ting er alltid enklere å se gjennom, og bestiller CSS-erklæringer (egenskaper med sine verdier) i henhold til en regel som gir fornuftige resultater i en bedre organisert kode.

Ta en titt på for eksempel WordPresss eiendomsbestemmelsesregler, den definerer følgende enkle, men logiske grunnlinje for bestilling der egenskaper er gruppert etter deres betydning:

1. Vise
2. posisjonering
3. Boksmodell
4. Farger og typografi
5. Annen

Enheter og verdier

Å avgjøre hvordan vi vil bruke enheter og verdier er ikke bare viktig for å oppnå et konsekvent kodeutseende, men også hvis vi ikke gjør det, kan vi ende opp med noe rart

Tenk deg et nettsted som alternativt bruker px, em, og rem lengde målinger. Det vil ikke bare se dårlig ut i kodeditoren, men mest sannsynlig vil enkelte elementer være overraskende små eller store på dette nettstedet.

Vi må også ta avgjørelser om fargeverdier (heksadesimale, rgb eller hsl), og om vi vil bruke stenografiegenskaper og i henhold til hvilke regler. Det er en instruksjon som er inkludert i alle CSS-kodestyringsguider jeg støte på, dvs.. Ikke spesifiser enheter for 0 verdier (egentlig, bare ikke).

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

kommenterer

Kommentarskode er viktig på alle språk, men i CSS det hjelper ikke bare feilsøking og dokumentasjon, men også seksjoner CSS regler i logiske grupper. Vi kan bruke enten / * ... * / eller // ... notatiestil for kommentarer i CSS, er det viktig å forbli konsistent med kommentarer gjennom hele vårt prosjekt.

Idiomatic CSS etablerer for eksempel et meningsfylt kommentarsystem som til og med bruker noen grunnleggende ASCII-kunst, og resulterer i vakkert organisert kode: