Så här optimerar du CSS med kodstylguider

När designers pratar om stilguider, menar de vanligtvis en överenskommen handbok på sammanhängande utseende av en webbplats eller en ansökan, med en väl utformad färgschema, typografi och användargränssnitt som används över hela projektet.

Det finns en annan typ av stil guide vi kan använda i webbutveckling också, och det är lika viktigt men mycket mer sällan diskuteras: stilguider för själva koden. Kodstylguider är snarare för utvecklare än designers, och deras huvudsyfte är att optimera CSS eller annan kod.

Att ange riktiga kodstylguider i bruk ger oss en bättre organiserad, konsekvent kodbas, förbättrad kodläsbarhet och mer underhållbar kod. Det är inte en slump att stora teknikföretag, som Google, AirBnB eller Dropbox, använder dem bra.

I det här inlägget tar vi en titt på hur vi kan smartisera vår CSS med hjälp av CSS-kodstylguider.

Kod stilguider vs mönsterbibliotek

I vår bransch finns en viss osäkerhet om vad vi kan kalla en stilguide. En lista bortsett från till exempel använder det synonymt med termen mönsterbibliotek i den här artikeln, men vi kan också stöta på denna typ av definition i andra inlägg.

Å andra sidan finns det också publikationer, som CSS Tricks eller Brad Frosts blogg, som skiljer kodstylguider från mönsterbibliotek. Detta senare tillvägagångssätt tar förmodligen oss närmare en väl optimerad webbplats, som Det tillåter oss att hantera kod och design separat, så vi kommer att använda det här i det här inlägget.

Både kodstödguider och mönsterbibliotek innehåller en stylingstrategi, men en annan typ. Mönsterbiblioteken, som Bootstrap, Zurb Foundation, BBCs Global Experience Language, eller MailChimps mönsterbibliotek, ger oss ett användargränssnitt med premade CSS-klasser, typografi, färgschema, ibland ett gallersystem och andra designmönster.

CSS-kodstylguider, som Evernote eller ThinkUp (eller de som nämns i intro) innehåller regler om hur man skriver CSS inklusive saker som namnkonventioner, filstruktur, egendomsordning, kodformatering, och andra.

Observera att generatorer för levande stilstyrkor, till exempel KSS, Styledown eller Pattern Lab, generera mönsterbibliotek och inte kodning stil guider. Även mönsterbibliotek är också mycket användbara och förhöjer webbutvecklingsprocessen tillåter de oss inte att optimera själva koden.

Bygg din CSS-kodstylguide

Det slutliga målet med en CSS-kodstylguide är att säkerställa att vi kan arbeta med en konsekvent, lättnedbrytbar kodbas som skrivits av utvecklare som alla följer samma kodstylningsregler. Att skapa en CSS kod stil guide kan ta lite tid men det är värt ansträngningen, eftersom vi bara behöver göra det en gång. Då kan vi använda samma stilguide över olika projekt.

Det är viktigt att notera att den bästa stilen guider innehåller inte bara stylingreglerna själva, men också exempel av bra och dålig användning, så att utvecklare kan förstå reglerna mer intuitivt.

Till exempel visar AirBnB bra och dåliga exempel på utvecklare på följande lätt smältbara sätt:

Filstruktur

Först måste vi räkna ut en logik enligt vilken vi kommer att organisera våra CSS-filer. För mindre projekt kan en CSS-fil vara tillräckligt, men för större är det alltid bättre att bryta upp koden, och sammanlänka de separata filerna senare i produktionen.

Vissa stilguider som ThinkUps, varnar oss också om Använd inte inline eller inbäddade stilar om det inte är oundvikligt Det är också en användbar regel som är värd att ansöka.

Nesting

Nesting är en bra funktion i CSS, men ibland kan det gå ur kontroll. Ingen känner sig särskilt glad, speciellt i mitten av en frustrerande felsökningsprocess, och stöter på extra långa väljare som följande:

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

Så det är alltid bra att upprätta en rimlig nestningsgräns, till exempel valde GitHub tre nivåer i sin stilguide. Genom att begränsa boet kan vi också tvinga oss att skriva en bättre strukturerad kod.

Naming Rules

Att använda koherenta namngivningsregler för CSS-väljare är avgörande om vi vill förstå våra kodmånader eller till och med år senare. Det finns många lösningar där ute, och Det finns bara en strikt regel som vi måste följa d.v.s. ett selektornamn kan inte börja med ett nummer.

De fyra vanliga stilar som används i selector namngivning är .små bokstäver, .under_scores, .dash-es, och .lowerCamelCase. Det är okej att välja någon av dem men vi måste följa samma logik över hela projektet.

Använder sig av endast semantiska väljare namn är också viktigt om vi vill ha meningsfull kod. Till exempel istället för .röd-knappen (vilket inte visar vad knappen gör) är det bättre att använda .alert-knappen namn (som säger vad det gör), så gör vi det möjligt för utvecklare (och vår framtida egen) att förstå vad den här knappen gör.

Dessutom om vi vill byta färg från rött till någonting annat i framtiden kan vi enkelt göra det utan krångel. Det finns också premade CSS namnkonventioner, såsom BEM (Block, Element, Modifier) ​​konventionen, som resultera i en konsekvent namngivningsstruktur med unika och meningsfulla namn.

Formateringsregler

Kodformatering inkluderar saker som användning av blankutrymme, flikar, indragning, mellanslag, radbrytningar etc. Det är inte riktigt en allmänt bra eller dålig metod vid formatering, den enda tumregeln är att välj sammanhängande regler som resulterar i en läsbar kod, och följ dem igenom.

Dropbox kräver till exempel att utvecklare sätter mellanslag efter kolon i egenskapsdeklarationer, medan Evernote använder två mellanslag för indragning. Vi kan ställa in så många formateringsregler som vi är bekanta med, men aldrig mer än det är möjligt att förstå.

Deklarationsorder

Beställda saker är alltid lättare att se igenom, och beställer CSS-deklarationer (egenskaper med sina värden) enligt en regel som ger meningsfulla resultat i en bättre organiserad kod.

Ta en titt på exempelvis WordPresss ordningsregler för fastigheter, den definierar följande enkla men logiska grundlinje för beställning där egenskaper grupperas enligt deras mening:

1. Visa
2. positionering
3. Boxmodell
4. Färger och typografi
5. Andra

Enheter och värden

Att bestämma hur vi vill använda enheter och värden är inte bara viktigt för att uppnå en konsekvent kodvisning, men även om vi inte gör det kan vi sluta med något konstigt

Tänk dig en webbplats som växelvis använder px, em, och rem längdmätningar. Det kommer inte bara att se dåligt ut i kodredigeraren, men sannolikt kommer vissa element att vara överraskande små eller stora på den webbplatsen.

Vi måste också fatta beslut om färgvärden (hexadecimal, rgb eller hsl), och om vi vill använda stenografiegenskaper och enligt vilka regler. Det finns en instruktion som ingår i varje CSS-kodstylguide jag stötte på, dvs. Ange inte enheter för 0-värden (egentligen bara inte).

.klass // bra marginal: 0; // dålig marginal: 0px; // dålig marginal: 0em; // dålig marginal: 0rem; 

kommentar

Kommentarskoden är nödvändig på alla språk, men i CSS Det underlättar inte bara felsökning och dokumentation, men även avsnitt CSS reglerar sig i logiska grupper. Vi kan antingen använda / * ... * / eller den // ... notationsstil för kommentarer i CSS, det viktiga är att förbli konsekvent med kommentarer i hela vårt projekt.

Idiomatic CSS etablerar till exempel ett meningsfullt kommentarsystem som även använder en viss grundläggande ASCII-konst och resulterar i vackert organiserad kod: