7 olulist nõuannet parema CSS-i kirjutamiseks

Programmeerimise üks suurimaid probleeme on hooldusega tegelemine. Reaalses stsenaariumis ei alusta me alati projektide arendamist nullist. Enamasti on meile määratud (või võtame) projekti, mis on juba paar aastat varem kirjutatud või isegi pikem.

Selle projektiga tõhusaks töötamiseks peame kõigepealt mõistma lähtekoodi. See on hetk, kui mõistame kohe puhta koodi tähtsust . Arendajatena peame proovima oma koodi kirjutada võimalikult puhtalt.

See kehtib ka CSS-i kohta. On mõningaid punkte, millele peame CSS-i kirjutamise ajal tähelepanu pöörama. Selles postituses tahaksin teiega jagada mõnda olulisemat. Usun, et need 7 nõuannet aitavad teil CSS-koodi kvaliteeti parandada.

Alustame siis ... ‌ ‌

1. KUIV

DRY tähistab "Ära korda iseennast" . See on tarkvaraarenduse üldpõhimõte ja seda saab rakendada igas programmeerimiskeeles, aga ka CSS-is. Nagu selle nimest aru saame, on DRY eesmärk korduste vältimine või vähendamine nii palju kui võimalik.

Näiteks saame luua 3 CSS-klassi kolme nupu jaoks:

.primary-button { background: blue; color: white; border-radius: 5px; padding: 10px 20px; text-align: center; font-size: 16px; } .form-button { background: green; color: white; border-radius: 5px; padding: 10px 20px; text-align: center; font-size: 16px; } .cancel-button { background: red; color: white; border-radius: 5px; padding: 10px 20px; text-align: center; font-size: 16px; }

Või võime kasutada põhimõtet DRY, kirjutades ühtsed reeglid üks kord lisaklassi ja erinevad reeglid teistes klassides:

.button { color: white; border-radius: 5px; padding: 10px 20px; text-align: center; font-size: 16px; } .primary-button { background: blue; } .form-button { background: green; } .cancel-button { background: red; }

Nagu näeme, väldib DRY põhimõtte rakendamine kordamist, vähendab ridade arvu ning parandab loetavust ja ühtlast jõudlust.

2. Nimetamine

CSS-i valijate nimetamine on veel üks oluline punkt parema CSS-i kirjutamiseks. Valija nimi peaks olema ennast kirjeldav ja loetav ...

// BAD NAMING .p { // Rules } .myFirstForm { // Rules }

Tavaliselt

on HTML-silt ja tähistab lõiku. Eespool ei saa me tegelikult aru, mis klass p on. Samuti peaksite vältima selliseid nimesid nagu myFirstForm ja ma ei soovita kasutada kaamelikohvrit .

Selle asemel kasutage deklaratiivseid nimesid (eraldatud mitme nime jaoks kriipsuga):

// GOOD NAMING .article-paragraph { // Rules } .contact-form { // Rules }

Nimed on minu meelest nüüd mõttekamad :)

Asjade nimetamine programmeerimises pole nii lihtne, kuid oma projektis saate kasutada erinevaid nimetamisviise. BEM (plokielemendi modifikaator) on üks neist. Olen varem töötanud BEM-iga ja oskan seda soovitada.

3. Ärge kasutage tekstisiseseid stiile

Noh, selle kohta on veebis argumente: mõned ütlevad, et ärge kunagi kasutage siseseid stiile, teised aga väidavad, et see võib mõnel juhul kasulik olla.

Minu arvates on parim tava tegelikult siseste stiilide mittekasutamine. Keskendun siin sellele, miks me ei peaks.

Murede lahutamine

Vastavalt murede lahususe põhimõttele tuleks disain (CSS), sisu (HTML) ja loogika (JavaScript) eraldada sellistel põhjustel nagu parem loetavus ja hooldus.

CSS-reeglite lisamine HTML-i siltidesse rikub seda reeglit:

 Some Text 
Peaksime pigem hoidma oma stiilireegleid välistes CSS-failides.

Otsingu raskused

Teine probleem inline-stiilide kasutamisel on see, et me ei saa neid otsida. Nii et kui me peame stiili muutma, otsime tavaliselt HTML-elemendi CSS-valijaid.

Muutkem näiteks oma veebilehe teksti fondisuurust . Selleks leiame kõigepealt brauseris selle konkreetse osa, kus muudatust on vaja, vaadates HTML-struktuuri:

 Some Text 

Siis peame leidma valija, mis on siin tekstirohke klass. Lõpuks läheme sellesse klassi ja teeme muudatused:

.text-bold { font-size: 16px; // change the font-size to 14px font-weight: bold; }

Kuid kui reeglid on kirjutatud klassisisese stiili asemel:

 Some Text 

Isegi kui leiame HTML-märgendi, ei saa me teada, kas HTML -i sees on muid fondisuuruse reegleid või mitte. Kuna valijat pole kasutatud, peame kõik HTML-lehed ükshaaval läbi vaatama, proovima leida teisi fondisuuruse reegleid ja neid ka muuta.

Kas CSS-valijaga pole lihtsam? Kuid on midagi veelgi hullemat ...

Konkreetsuse / ülekirjutamise probleemid

Inline-stiilidel on CSS-i valijate seas kõrgeim spetsiifika (kui me ei loe ! Olulisi silte ).

Arvestades, et kasutame elemendi jaoks nii klassi kui ka tekstisisest stiili:

.text-bold { font-size: 16px; font-weight: bold; }
 Some Text 

Siin font-size teksti on 14px , sest inline-stiile on kõrgem spetsiifilisus kui CSS klasse. Kui muudate klassis:

.text-bold { font-size: 20px; font-weight: bold; }

Fondi suurus on endiselt 14px. Nii et teie muudatus CSS-klassis ei toimi, mis paneb teid lõpuks ütlema:

"Hei, miks mu CSS-kood ei tööta? Ma vihkan CSS-i!"

ja suunake teid kasutama ! olulist silti, mis võlub:

.text-bold { font-size: 20px !important; font-weight: bold; }

Mis on suur ei-ei ja viib meid järgmise punkti juurde ...

4. Avoid the !important tag

OK, so your CSS wasn't working as was supposed to, and you made it work by applying the important tag:

!important

What happens next? The !important tag has the highest specificity of all CSS selectors.

You're basically saying to the browser to apply that specific rule with the !important tag always and under any circumstances. This is not good because CSS rules can differ from one selector to another, from parent selector to child.

The only way to override an important tag is to use another important tag. And this leads to using more and more important tags. Trust me, in the near future your project code will be full of !important tags, which makes your CSS code much harder to maintain. So try not to use it.

5. Use a Preprocessor

Working with a CSS Preprocessor like Sass or LESS is very useful in bigger projects. A preprocessor brings additional features to our CSS code that we normally can't do.

For example, we can define variables, functions and mixins, we can import & export our CSS files in other CSS files and we can write nested CSS code:

A preprocessor has its own syntax and later it gets translated into standard CSS (in a separate CSS file) because browsers don't understand the syntax.

I like working with Sass and have used it in various projects. I have covered some of the advantages of using a CSS Preprocessor here.

6. Use Shorthands

Some of the CSS properties like paddings, margins, fonts and borders can be written in a much simpler way by shorthands. Using shorthands helps to reduce the lines of rules.

So without shorthands, a CSS class would look like this:

.article-container { padding-top: 10px; padding-bottom: 20px; padding-left: 15px; padding-right: 15px; margin-top: 10px; margin-bottom: 10px; margin-left: 15px; margin-right: 15px; border-width: 1px; border-style: solid: border-color: black; }

and with shorthands it looks like this:

.article-container { padding: 10px 15px 20px 15px; margin: 10px 15px; border: 1px solid black; }

You can find here more info about how to use shorthands properties and for which CSS properties they can be applied.

7. Add Comments When Necessary

Normally, quality code doesn't need comments because it should already be clear and self-descriptive. But still, in some cases, we may need to write additional explanations.

// Your Comments .example-class { // your rules }

So when you feel that some parts of the code are unclear, then don't be afraid to add comments (but on the other hand, make sure not to overdo it :)).

As a Frontend Developer with a couple of years of experience, these are the most important tips that I can suggest for improving your CSS skills. If you have any questions, or you think there are also other tips for writing better CSS, don't hesitate to comment down below.

Kui soovite veebiarenduse kohta rohkem teada saada, jälgige mind julgelt Youtube'is !

Aitäh, et lugesid!