Share
Å få vår kode gjennomgått av et proff er en flott måte å forbedre kodekvaliteten på, men hva skjer hvis du ikke har tilgang til en rockstar-programmerer? Du gjør det neste beste, og ta en "lint" for det språket.
I dag vil jeg snakke litt om CSSLint, et nylig utgitt kodeanalyseværktøy for, du gjettet det, CSS. Bli med meg etter hoppet!
La oss slå Wikipedia for en definisjon:
Lint er et verktøy som flagger mistenkelig bruk i programvare skrevet på hvilket som helst dataspråk.
I utgangspunktet ser et lint på koden vår og sjekker om dårlig programmeringspraksis. Udefinerte variabler, ineffektive konstruksjoner, slike ting.
Du lurer sikkert på hvorfor du noen gang vil trenge et slikt verktøy. La oss innse det: Ikke alle av oss har høyeste kunnskap om hva vi jobber med, eller har lyst til å få våre kodesamtaler vurdert. I disse tilfellene er det best mulig å stikke vår kode i et lint. Og i motsetning til opprydding verktøy spretter lint ut tidbits om koden din og hvordan du kan forbedre den.
CSSLint er laget av Nicholas Zakas og Nicole Sullivan, et åpen kildekodeverktøy som kontrollerer syntaxen din mot et sett med forhåndsdefinerte regler for å utrydde mulige ineffektiviteter og sørge for at presentasjonen fungerer som forventet med små overraskelser.
Etter at du har gått over til CSSLint-siden, kan du bare lime inn i kilden CSS og velge hvilke regler du vil håndheve. Trykk på lintknappen og CSSLint vil begynne å ødelegge din smugness.
Hvis du er en Node junkie som meg, er det også en versjon for det. Bare skriv inn sudo npm installer -g csslint og du er god til å gå!
La oss ta en rask titt på reglene som CSSLint håndhever.
Hvis du er noe som meg, må noen av reglene ha hatt deg flummoxed.
Helt ærlig, ja, nei og alt i mellom.
Etter å ha lurket på en rekke diskusjonsforum og IRC-rom, fant jeg ut at mange utviklere synes å være i opprør over reglene og kanskje riktig. La meg forsøke å forklare hvorfor de fleste reglene gir mening, men andre gjør det ikke.
IDer bør ikke brukes i selektorer fordi disse reglene er for tette kombinert med HTML og har ingen mulighet for gjenbruk. Det er mye å foretrekke å bruke klasser i selektorer og deretter bruke en klasse til et element på siden.
Denne slått en nerve med mange utviklere siden vi er ganske vant til å tildele ID for de viktigste strukturelle komponentene i en layout som topptekst og bunntekst.
CSSLint hevder at stylingen for slike elementer per definisjon ikke kan gjenbrukes direkte. Hvis du vil ha to sidebjelker på siden din, lar en klasse deg bruke styling mens en ID ikke vil.
Husk at bare fordi en klasse kan gjenbrukes, betyr det ikke at den må være. Unike klasser er helt akseptable og en svulmende måte å gjenbruke styling hvis behovet oppstår.
Overskriftselementer (h1-h6) skal defineres som toppnivåer og ikke scoped til bestemte områder på siden.
De fleste utviklere, inkludert meg, har blitt vant til å skrive kontekstavhengige overskrifter. Som i definerer vi separat styling for overskrifter avhengig av, si hvilken side den vises på. Et argument i favør av denne tilnærmingen er at det beveger seg helt fra merkenavn til stilarket. Du kan bare definere en tag og la CSS-kaskaden i samsvar med dette.
CSSLint hevder at en slik tilnærming kompromitterer forutsigbarheten av designet ditt. Hvis noen andre skulle plukke opp ditt design og prøvde å sette inn en overskrift et sted, måtte han / hun være oppmerksom på konteksten og plasseringen av elementet. Med overskrifter definert ubetinget, kan han eller hun bruke en overskrift som er trygg på presentasjonen, uavhengig av foreldrene sine.
Overskriftselementer (h1-h6) skal ha nøyaktig en regel på et nettsted.
En utvidelse av regelen ovenfor for å forbedre forutsigbarheten av presentasjonen. Riktig eller feil, husk at dette i utgangspunktet utelukker, inkludert en slags tilbakestillingskode i stilarket. Hvert resetark fungerer også på overskriftene dine, og dermed vil CSSLint markere det som en feil.
Tilgrensende klasser ser ut som .foo.bar. Mens det er teknisk tillatt i CSS, håndteres de ikke riktig av Internet Explorer 6 og tidligere.
Med denne regelen aktivert, regner CSSLint-flaggene som .nav.red, med den offisielle grunnen er at Internet Explorer 6 og under ikke spiller bra med selgeren. Jeg respekterer utviklerne, men jeg må være uenig her. Bare fordi det ikke fungerer med Internett 'Dev-buster' Explorer 6 Det er ikke en god grunn til å slutte å jobbe med en nyttig funksjon.
Border og polstring legger til plass utenfor elementets innhold. Innstilling av bredde eller høyde sammen med grenser og polstring er vanligvis en feil fordi du ikke får det visuelle resultatet du leter etter. CSS Lint advarer når en regel bruker bredde eller høyde i tillegg til polstring og / eller kantlinje.
Boksmodellen er kanskje ødelagt, men nesten alle frontender-utviklere jeg vet er nært oppmerksom på manglene og hvordan man kan overvinne forskjellene med implementering. Er vi virkelig klare til å gi opp et lag av kontroll fordi noen eldre nettlesere har en annen implementering?
Bruke webfonter kommer med ytelsesimplikasjoner, da fontfiler kan være ganske store, og noen nettlesere blokkerer gjengivelse mens de lastes ned. Av denne grunn vil CSS Lint advare deg når det er mer enn fem webfonter i et stilark.
Jeg forutser ikke en situasjon der jeg bruker mer enn fem skrifter på en side, men jeg føler at dypping inn i dette området er litt tvilsomt. Hvis noe, dette er et designfeil enn en utviklingsfeil. Hvis en utvikler refererer til fem separate skrifttyper i stilarket, er det sjansene, det er ikke ved et uhell.
CSS Lint sjekker bare for å se om du har brukt float mer enn 10 ganger, og i så fall viser en advarsel. Ved hjelp av dette betyr mange flyter vanligvis at du trenger en form for abstraksjon for å oppnå oppsettet.
Mens jeg er enig med skaperens argument om at det å ha mer enn ti tilfeller av flyt er en dårlig ide, føler jeg også at dette vil påvirke merkingen en gang over en gitt størrelse.
For eksempel, i en situasjon hvor du vil flyte to elementer, vil du tradisjonelt bruke:
? og styling, etter tradisjonelle metoder.
.beholder-1 bredde: 70%; flyte: venstre; .container-2 width: 30%; flyte: venstre;
CSSLint-metoden ville være å abstrahere flyten som sådan:
? og styling slik:
.beholder-1 bredde: 70%; .container-2 width: 30%; .flate float: left;
Mens jeg er enig i at dette er en levedyktig tilnærming, føler jeg at oppslaget vil bli betydelig overfylt når du prøver å abstrahere mer unna. Jeg vil heller se en klasse som inneholder det meste av stylingen på ett sted enn å rote markeringen med 10+ klasser. Igjen føler jeg at dette er et subjektivt tema.
Alle reglene ovenfor overholder gjeldende standard praksis. Det er sikkert at noen av reglene har liten ekte verdensbetydning, som nullverdier som ikke trenger enheter, eller vil bli fanget av en anstendig IDE, som å analysere feil, men likevel er disse gode regler å ha i en CSS test suite.
CSSLint skal hjelpe mange utviklere nedover veien, men?
CSSLint er uten tvil skrevet av utviklere med gode legitimasjonsbeskrivelser og vil definitivt hjelpe mange utviklere og designere nedover veien.
Hva jeg finner litt irksome er at mange av de kontroversielle reglene kommer fra Objektorientert CSS, et CSS-rammeverk som skal la utviklere skrive vedlikeholdsbar CSS. Mens jeg ikke har noe mot rammen, og dens paradigme, må du være enig i at det er en måte å gjøre ting på, ikke de måte å gjøre ting på.
I motsetning til JSLint hvor jeg føler at alle reglene gir mening, med CSSLint, føles det som om jeg blir fortalt at en stil med å skrive CSS er riktig og de andre har feil. Det ville være som noen som ber meg om å gi opp Beatles fordi Rolling Stones er deres foretrukne band.
Verktøy er bare det - verktøy.
Selvfølgelig har vi, som en gruppe, en tendens til å være ganske klamrende når det gjelder vår kode. Vi liker ikke å høre at vår kode kan ha * gis * potensielle problemer eller skrives på en helt annen måte.
Det viktigste å merke seg her er at CSSLint er til slutt et verktøy. Det lar deg bare vite at noen av områdene kan har feil.
CSSLint trenger ikke å være jernnoten rundt som du baserer hele egoet på. Det er ingen grunn til å bøye seg bakover for å unngå en advarsel hvis du vet nøyaktig hva du gjør.
Ja.
I CSS, som i integral kalkulator, er det mange løsninger på et gitt problem. Det er nødvendigvis ikke en "best" måte å gjøre ting på - du kan favorisere lesbarhet mens jeg kan favorisere effektiviteten. Det som er viktig er at du innser at hver og en av oss har vår unike måte å gjøre ting på.
Hvis du ikke har samme perspektiver for å løse et problem, kan du være uenig med en annen tilnærming og kan til og med finne det tvilsomt.
Når det er sagt, er det aldri en god grunn til ikke å lære nye ting. Å se på problemer fra et annet utviklingsperspektiv er en fin måte å se om du kan lære noe nytt.
Hva synes du om CSSLint? Finn det nyttig? Forvirrende? Har det hjulpet med din virkelige verden problemer? Gi oss beskjed i kommentarene.
Vær utmerket til hverandre og takk så mye for å lese!
Accentsconagua