Share
Onze code laten beoordelen door een pro is een geweldige manier om de codekwaliteit te verbeteren, maar wat gebeurt er als je geen toegang hebt tot een rockstar-programmeur? Je doet het beste en grijpt een plukje voor die taal.
Vandaag zou ik graag iets willen vertellen over CSSLint, een recent uitgebrachte code-analyse-tool voor, u raadt het al, CSS. Ga met me mee na de sprong!
Laten we Wikipedia raken voor een definitie:
Lint is een tool die verdacht gebruik markeert in software geschreven in elke computertaal.
Kortom, een lintje kijkt naar onze code en controleert op slechte programmeermethoden. Ongedefinieerde variabelen, inefficiënte constructies, dat soort dingen.
Je vraagt je waarschijnlijk af waarom je zo'n tool ooit nodig zou hebben. Laten we eerlijk zijn: niet iedereen bezit de allerhoogste kennis van waar we mee werken of hebben de luxe om onze code peer-reviewed te krijgen. In deze gevallen is het de volgende beste optie om onze code in een pluis te steken. En in tegenstelling tot het opschonen van gereedschappen, spuugt lintjes uit wat u weet over uw code en hoe u deze kunt verbeteren.
CSSLint is gemaakt door Nicholas Zakas en Nicole Sullivan en is een open source-tool die je syntaxis tegen een reeks vooraf gedefinieerde regels controleert om mogelijke inefficiënties uit te roeien en ervoor te zorgen dat je presentatie werkt zoals verwacht met weinig verrassingen.
Nadat u naar de CSSLint-site bent gegaan, kunt u alleen uw bron-CSS plakken en kiezen welke regels u wilt afdwingen. Druk op de lintknop en CSSLint begint je zelfvoldaanheid te eroderen.
Als je een Node Junkie bent zoals ik, is daar ook een versie voor. Typ gewoon in sudo npm install -g csslint en je bent klaar om te gaan!
Laten we even kijken naar de regels die CSSLint afdwingt.
Als je zoiets als ik bent, dan zijn er een paar regels die je hebben laten afromen.
Eerlijk gezegd, ja, nee en alles daar tussenin.
Na een tijdlang op een aantal discussieborden en IRC-kamers geluisterd te hebben, kwam ik erachter dat veel ontwikkelaars in opschudding lijken te verkeren boven de regels en misschien wel gelijk. Laat me proberen uit te leggen waarom de meeste regels logisch zijn, maar andere niet.
ID's mogen niet worden gebruikt in selectors omdat deze regels te nauw gekoppeld zijn aan de HTML en geen mogelijkheid tot hergebruik hebben. Het heeft veel de voorkeur om klassen in selectors te gebruiken en vervolgens een klasse toe te passen op een element op de pagina.
Deze sloeg een lef met veel ontwikkelaars, omdat we vrij gewend zijn om ID's toe te wijzen voor de belangrijkste structurele componenten van een lay-out zoals de kop- en voettekst..
CSSLint betoogt dat de vormgeving van dergelijke elementen per definitie niet direct kan worden hergebruikt. Als u dubbele zijbalken op uw pagina wilt, kunt u met een klasse de stijl opnieuw gebruiken terwijl een ID dat niet doet.
Houd in gedachten dat alleen omdat een klasse opnieuw kan worden gebruikt, niet betekent dat het moet zijn. Unieke klassen zijn perfect acceptabel en een geweldige manier om styling te hergebruiken als dat nodig is.
Koerselementen (h1-h6) moeten worden gedefinieerd als stijlen op het hoogste niveau en niet naar bepaalde delen van de pagina.
De meeste ontwikkelaars, waaronder ikzelf, zijn gewend geraakt aan het schrijven van contextgevoelige headers. Net als in, definiëren we een afzonderlijke stijl voor headers, afhankelijk van bijvoorbeeld op welke pagina deze wordt weergegeven. Een argument ten gunste van deze benadering is dat het alle elementen van de opmaak naar het stijlblad verplaatst. U kunt alleen een tag definiëren en de CSS-cascade overeenkomstig laten.
CSSLint betoogt dat een dergelijke benadering de voorspelbaarheid van uw ontwerp in gevaar brengt. Als iemand anders je ontwerp zou ophalen en ergens een kop in zou willen zetten, zou hij / zij op de hoogte moeten zijn van de context en plaatsing van het element. Als de koppen onvoorwaardelijk zijn gedefinieerd, kan hij of zij overal een naam gebruiken die zeker is van de presentatie, ongeacht zijn ouders.
Koerselementen (h1-h6) moeten exact één regel op een site hebben.
Een uitbreiding van de bovenstaande regel om de voorspelbaarheid van de presentatie te verbeteren. Juist of verkeerd, onthoud dat dit in principe uitsluit dat je een soort resetcode in je stylesheet opneemt. Elk resetblad werkt ook op uw kop en CSSLint zal het als een fout markeren.
Aangrenzende klassen zien eruit als .foo.bar. Hoewel technisch toegestaan in CSS, worden deze niet goed behandeld door Internet Explorer 6 en eerder.
Met deze regel ingeschakeld, markeert CSSLint regels zoals .nav.red, met de officiële reden dat Internet Explorer 6 en hieronder niet goed spelen met de selector. Ik respecteer de ontwikkelaars maar ik ben het hier niet mee eens. Alleen omdat het niet werkt Internet 'Dev-buster' Explorer 6 is geen goede reden om te stoppen met werken met een handige functie.
Randen en opvulling voegen ruimte toe buiten de inhoud van een element. Het instellen van de breedte of hoogte samen met randen en opvulling is meestal een vergissing omdat u niet het visuele resultaat krijgt waarnaar u op zoek bent. CSS lint waarschuwt wanneer een regel breedte of hoogte gebruikt naast opvulling en / of rand.
Het doosmodel is misschien gebroken maar bijna elke front-end ontwikkelaar die ik ken, is op de hoogte van de tekortkomingen en hoe de ongelijkheden met de implementatie kunnen worden overwonnen. Zijn we echt klaar om een laag controle op te geven, omdat sommige oudere browsers een andere implementatie hebben?
Het gebruik van weblettertypen heeft implicaties voor de prestaties, aangezien lettertypebestanden behoorlijk groot kunnen zijn en sommige browsers de weergave blokkeren tijdens het downloaden. Om deze reden waarschuwt CSS Lint u wanneer er meer dan vijf weblettertypen in een stylesheet staan.
Ik voorzie geen situatie waarin ik meer dan vijf lettertypen op een pagina zou gebruiken, maar ik denk dat het een beetje twijfelachtig is om dit gebied te betreden. Als er al iets is, is dit een ontwerpfout dan een ontwikkelingsfout. Als een ontwikkelaar verwijst naar vijf afzonderlijke lettertypen in zijn stylesheet, is de kans groot dat dit niet per ongeluk gebeurt.
CSS Lint controleert eenvoudig of u meer dan 10 keer float hebt gebruikt en geeft zo nodig een waarschuwing weer. Het gebruik van deze vele drijvers betekent meestal dat je een soort van abstractie nodig hebt om de lay-out te bereiken.
Hoewel ik het eens ben met het argument van de makers dat het hebben van meer dan tien keer floaten een slecht idee is, heb ik ook het gevoel dat dit van invloed is op de markup na een bepaald formaat.
Bijvoorbeeld, in een situatie waarin je twee elementen wilt laten zweven, zou je traditioneel gebruik maken van:
? en de styling, volgens traditionele methoden.
.container-1 breedte: 70%; zweven: links; .container-2 width: 30%; zweven: links;
De CSSLint-methode zou de float als volgt abstraheren:
? en styling zoals zo:
.container-1 breedte: 70%; .container-2 width: 30%; .float float: left;
Hoewel ik het ermee eens ben dat dit een haalbare aanpak is, ben ik van mening dat de opmaak beduidend drukker zal worden zodra je probeert om meer weg te abstraheren. Ik zie liever een klasse met het grootste deel van de vormgeving op één plaats staan dan de opmaak overbodig maken met meer dan 10 klassen. Nogmaals, ik voel dat dit een subjectief onderwerp is.
Alle bovenstaande regels zijn in overeenstemming met de huidige standaardpraktijken. Natuurlijk, sommige regels hebben weinig echte betekenis, zoals nulwaarden die geen eenheden nodig hebben, of worden gepakt door een fatsoenlijke IDE, zoals parseerfouten, maar toch zijn dit goede regels in een CSS-testsuite.
CSSLint gaat veel ontwikkelaars onderweg helpen, maar?
CSSLint is ongetwijfeld geschreven door ontwikkelaars met geweldige inloggegevens en zal zeker veel ontwikkelaars en ontwerpers op weg helpen.
Wat ik een beetje vervelend vind, is dat veel van de controversiële regels komen van Object Oriented CSS, een CSS-framework dat bedoeld is om ontwikkelaars een onderhoudbare CSS te laten schrijven. Hoewel ik niets heb tegen het raamwerk en het paradigma, moet je toegeven dat het een manier is om dingen te doen, niet de manier om dingen te doen.
In tegenstelling tot JSLint, waar ik vind dat alle regels logisch zijn, voelt het bij CSSLint aan alsof ik te horen krijg dat één stijl van schrijven van CSS klopt en dat de anderen het bij het verkeerde eind hebben. Het zou hetzelfde zijn als iemand die me vraagt de Beatles op te geven omdat Rolling Stones hun favoriete band is.
Tools zijn precies dat - tools.
Natuurlijk zijn we als groep nogal clingy als het gaat om onze code. We vinden het niet leuk om te horen dat onze code problemen kan veroorzaken of op een geheel andere manier kan worden geschreven.
Het belangrijkste om hier nota van te nemen is dat CSSLint uiteindelijk een hulpmiddel is. Het laat je alleen maar weten dat sommige gebieden mei fouten hebben.
CSSLint hoeft niet de ijzeren vuist te zijn waar je je hele ego op baseert. Er is geen reden om voorover te buigen om een waarschuwing te vermijden als je precies weet wat je doet.
Ja.
In CSS, zoals in de integrale calculus, zijn er veel oplossingen voor een bepaald probleem. Er is noodzakelijkerwijze geen 'beste' manier om dingen te doen - je kunt de leesbaarheid bevorderen, terwijl ik de efficiëntie kan bevorderen. Wat belangrijk is, is dat je je realiseert dat iedereen van ons onze unieke manier van doen heeft.
Als u niet dezelfde perspectieven heeft om een probleem op te lossen, bent u het misschien niet eens met een andere aanpak en kunt u het zelfs twijfelachtig vinden.
Dat gezegd hebbende, is er nooit een goede reden om geen nieuwe dingen te leren. Als u problemen vanuit het perspectief van een andere ontwikkelaar bekijkt, is dit een geweldige manier om te zien of u iets nieuws kunt leren.
Wat denk je van CSSLint? Vind je het nuttig? Verwarrend? Heeft het geholpen met uw problemen in de echte wereld? Laat het ons weten in de comments.
Wees uitstekend voor elkaar en bedankt voor het lezen!
Accentsconagua