CSS optimaliseren met codestijlgidsen

Wanneer ontwerpers het hebben over stijlgidsen, bedoelen ze dat meestal een overeengekomen handleiding op de coherente look en feel van een website of een applicatie, met een goed ontworpen kleurenschema, typografie en UI dat wordt gebruikt in het hele project.

Er is nog een ander soort stijlgids die we ook kunnen gebruiken bij webontwikkeling, en het is net zo belangrijk, maar er wordt zelden meer over gesproken: stijlgidsen voor de code zelf. Gidsen met codestijlen zijn eerder voor ontwikkelaars dan voor ontwerpers, en hun belangrijkste doel is om CSS of andere code te optimaliseren.

Het gebruik van de juiste codestijlgidsen biedt ons een beter georganiseerde, consistente codebasis, verbeterde codele leesbaarheid en meer onderhoudbare code. Het is geen toeval dat grote technische bedrijven zoals Google, AirBnB of Dropbox er goed gebruik van maken.

In deze post zullen we bekijken hoe we onze CSS slim kunnen optimaliseren met behulp van CSS-codestijlgidsen.

Gidsen voor codestijl versus patroonbibliotheken

In onze branche bestaat er een zekere mate van onzekerheid over wat we een stijlgids kunnen noemen. Een lijst uit elkaar gebruikt het bijvoorbeeld als synoniem voor de term patroonbibliotheek in dit artikel, maar we kunnen dit soort definities ook tegenkomen in andere berichten.

Aan de andere kant zijn er ook publicaties, zoals CSS Tricks of Brad Frost's blog, die codestijlgidsen van patroonbibliotheken onderscheiden. Deze laatste benadering brengt ons waarschijnlijk dichter bij een goed geoptimaliseerde website, zoals het stelt ons in staat om code en ontwerp apart af te handelen, dus we zullen dit in deze post gebruiken.

Zowel codestijlgidsen als patroonbibliotheken bevatten een stylingstrategie, maar een andere soort. Patroonbibliotheken, zoals Bootstrap, Zurb Foundation, BBC's Global Experience Language, of de patroonbibliotheek van MailChimp, voorzien ons van een UI met vooraf gedefinieerde CSS-klassen, typografie, kleurenschema, soms een rastersysteem en andere ontwerppatronen.

CSS-codestijlgidsen, zoals Evernote's of ThinkUp's (of degene die in de intro worden genoemd) bevatten regels over hoe CSS te schrijven inclusief dingen zoals naamgevingsconventies, bestandsstructuur, eigenschapvolgorde, codering, en anderen.

Merk op dat gidsgeneratoren voor levende stijlen, zoals KSS, Styledown of Pattern Lab, maak patroonbibliotheken en niet codeerstijlgidsen. Hoewel patroonbibliotheken ook zeer nuttig zijn en het webontwikkelingsproces verbeteren, laten ze ons niet toe om de code zelf te optimaliseren.

Bouw uw CSS Code Style Guide

Het uiteindelijke doel van een handleiding voor CSS-codestijlen is om ervoor te zorgen dat we kunnen werken met een consistente, eenvoudig te debuggen codebase geschreven door ontwikkelaars die allemaal dezelfde regels voor codestijl volgen. Het maken van een CSS-codestijlgids kan enige tijd duren, maar het is de moeite waard, omdat we het maar één keer hoeven te doen. Dan kunnen we dezelfde stijlgids gebruiken voor verschillende projecten.

Het is belangrijk om op te merken dat de beste stijlgidsen zijn bevatten niet alleen de stylingregels zelf, maar ook voorbeelden van goed en slecht gebruik, op deze manier kunnen ontwikkelaars intuïtiever de regels begrijpen.

AirBnB toont bijvoorbeeld goede en slechte voorbeelden voor ontwikkelaars op de volgende gemakkelijk verteerbare manier:

Bestandsstructuur

Eerst en vooral moeten we een logica bedenken om onze CSS-bestanden te ordenen. Voor kleinere projecten kan één CSS-bestand voldoende zijn, maar voor grotere projecten wel altijd beter om de code te verbreken, en voeg de afzonderlijke bestanden later in productie samen.

Sommige stijlgidsen zoals ThinkUp waarschuwen ons ook voor geen inline of ingesloten stijlen gebruiken tenzij het onvermijdelijk is; het is ook een handige regel die de moeite waard is om toe te passen.

nesting

Nesten is een geweldige functie in CSS, maar soms kan het uit de hand lopen. Niemand voelt zich bijzonder gelukkig, vooral in het midden van een frustrerend debug-proces en botst tegen extra lange selectors zoals deze:

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

Dus het is altijd goed om een redelijke nestelgrens instellen, GitHub koos bijvoorbeeld drie niveaus in zijn stijlgids. Door nesting te beperken kunnen we onszelf ook dwingen een beter gestructureerde code te schrijven.

Regels benoemen

Het gebruik van coherente naamgevingsregels voor CSS-kiezers is cruciaal als we onze codemaand of zelfs jaren later willen begrijpen. Er zijn veel oplossingen die er zijn, en er is maar één strikte regel die we moeten volgen d.w.z. een selector naam kan niet beginnen met een nummer.

De vier algemene stijlen die worden gebruikt bij het kiezen van selectors zijn .kleine letters, .under_scores, .dash-es, en .lowerCamelCase. Het is prima om een ​​van deze te kiezen, maar we moeten in het hele project dezelfde logica volgen.

Gebruik makend van alleen semantische selectornamen is ook essentieel als we dat willen hebben zinvolle code. Bijvoorbeeld in plaats van .rode knop (wat niet laat zien wat de knop doet) is het beter om de .alert-knop name (wat zegt wat het doet), op deze manier stellen we ontwikkelaars (en ons toekomstige zelf) in staat te begrijpen wat die knop doet.

Bovendien als we in de toekomst de kleur van rood naar iets anders willen veranderen, kunnen we dat zonder gedoe doen. Er zijn ook vooraf gedefinieerde CSS naamgevingsconventies, zoals de BEM (Block, Element, Modifier) ​​conventie resulteren in een consistente naamgevingsstructuur met unieke en betekenisvolle namen.

Opmaakregels

Code-opmaak omvat zaken zoals het gebruik van witruimte, tabs, inspringing, spatiëring, regeleinden, etc. Er is niet echt een universeel goede of slechte methode in formatteren, de enige vuistregel is om kies coherente regels die resulteren in een leesbare code, en volg ze door.

Dropbox vereist bijvoorbeeld dat ontwikkelaars spaties achter de dubbele punt plaatsen in de declaraties van objecten, terwijl Evernote twee spaties gebruikt voor inspringen. We kunnen zoveel opmaakregels instellen als we comfortabel vinden, maar nooit meer dan het mogelijk is om te begrijpen.

Declaratievolgorde

Bestelde dingen zijn altijd beter door te zien, en CSS-verklaringen bestellen (eigenschappen met hun waarden) volgens een regel die logisch is, resulteert dit in een beter georganiseerde code.

Bekijk bijvoorbeeld de regels voor het ordenen van eigendommen van WordPress, het definieert de volgende eenvoudige maar logische basislijn om te ordenen waarin eigenschappen zijn gegroepeerd op hun betekenis:

1. tonen
2. positionering
3. Doosmodel
4. Kleuren en typografie
5. anders

Eenheden en waarden

Beslissen over hoe we eenheden en waarden willen gebruiken, is niet alleen belangrijk om een ​​consistent uiterlijk van de code te krijgen, maar ook als we dit niet doen, kunnen we eindigen met iets raars

Stelt u zich eens een site voor die afwisselend gebruikt px, em, en rem lengtematen. Het ziet er niet alleen slecht uit in de code-editor, maar waarschijnlijk zullen sommige elementen verrassend klein of groot zijn op die site.

We moeten ook beslissingen nemen over kleurwaarden (hexadecimaal, rgb of hsl) en of we stenografische eigenschappen willen gebruiken en volgens welke regels. Er is een instructie die is opgenomen in elke CSS-codestijl die ik tegenkwam, d.w.z.. geef geen eenheden op voor 0-waarden (echt, doe het gewoon niet).

.class // good margin: 0; // slechte marge: 0px; // slechte marge: 0em; // slechte marge: 0rem; 

In een reactie

Commentaarcode is essentieel in alle talen, maar in CSS het vergemakkelijkt niet alleen het debuggen en het maken van documentatie, maar ook secties CSS-regels in logische groepen. We kunnen de / * ... * / of de // ... notatiestijl voor opmerkingen in CSS, het belangrijkste is om blijf consistent met opmerkingen gedurende ons hele project.

Idiomatische CSS bijvoorbeeld, stelt een zinvol commentaarsysteem in dat zelfs enige standaard ASCII-kunst gebruikt, en resulteert in prachtig georganiseerde code: