Share
Att få vår kod granskad av ett proffs är ett bra sätt att förbättra kodkvaliteten, men vad händer om du inte har tillgång till en rockstar-programmerare? Du gör nästa bästa sak och ta en "ludd" för det språket.
Idag vill jag prata lite om CSSLint, ett nyligen släppt kodanalysverktyg för att du gissade det, CSS. Gå med mig efter hoppet!
Låt oss slå Wikipedia för en definition:
Lint är ett verktyg som flaggar misstänkt användning i programvara som skrivs på vilket datorspråk som helst.
I princip tittar en ludd på vår kod och kontrollerar om dålig programmeringspraxis. Odefinierade variabler, ineffektiva konstruktioner, saker som så.
Du undrar nog att du någonsin behöver ett sådant verktyg. Låt oss möta det: inte alla har högkännedom om vad vi jobbar med eller har lyxen att få vår kodbedömning granskad. I de här fallen klarar vi vår kod i ett lint som nästa bästa alternativ. Och till skillnad från rengöringsverktyg spetsar linten ut prat om din kod och hur man förbättrar det.
Skapat av Nicholas Zakas och Nicole Sullivan är CSSLint ett open source-verktyg som kontrollerar din syntax mot en uppsättning fördefinierade regler för att utrota möjliga ineffektiviteter och se till att din presentation fungerar som förväntat med små överraskningar.
Efter att ha kommit över till CSSLint-webbplatsen kan du bara klistra in i din källkod och välja vilka regler du vill ha verkställt. Tryck på lintknappen och CSSLint börjar förstöra din smugness.
Om du är en Node-skräp som jag, finns det en version för det också. Skriv bara in sudo npm installera -g csslint och du är bra att gå!
Låt oss ta en snabb titt på de regler som CSSLint verkställer.
Om du är något som jag, måste några av reglerna ha haft dig flummoxed.
Helt uppriktigt, ja, nej och allt däremellan.
Efter att ha lurat på ett antal diskussionsforum och IRC-rum, fick jag reda på att många utvecklare verkar vara upprörda över reglerna och kanske rättvisa. Låt mig försöka förklara varför de flesta reglerna är meningsfulla, men andra gör det inte.
ID bör inte användas i selektorer eftersom dessa regler är för tätt kopplade till HTML och har ingen möjlighet att återanvändas. Det är mycket föredraget att använda klasser i väljare och sedan tillämpa en klass på ett element på sidan.
Den här slog en nerv med många utvecklare eftersom vi är vana vid att tilldela ID för de viktigaste strukturella komponenterna i en layout som sidhuvud och sidfot.
CSSLint hävdar att stilen för sådana element per definition inte kan återanvändas direkt. Om du vill ha dubbla sidfält på din sida kan du i klassen återanvända styling medan ett ID inte kommer att göra det.
Tänk på att bara för att en klass kan återanvändas betyder det inte att det måste vara. Unika klasser är helt acceptabla och sväller sätt att återanvända styling om behovet uppstår.
Rubrikelement (h1-h6) bör definieras som toppnivåer och inte scoped till specifika delar av sidan.
De flesta utvecklare, inklusive mig, har blivit vana vid att skriva kontextkänsliga rubriker. Som i definierar vi separat styling för rubriker beroende på, vilken sida den visas på. Ett argument till förmån för detta tillvägagångssätt är att det rör sig om allt från markeringen till stilarket. Du kan bara definiera en tagg och låta CSS-kaskaden följas.
CSSLint hävdar att ett sådant tillvägagångssätt äventyrar förutsägbarheten hos din design. Om någon annan skulle hämta din design och försökte lägga in en rubrik någonstans, skulle han / hon behöva vara medveten om kontexten och placeringen av elementet. Med rubriker definierade ovillkorligt kan han eller hon använda en rubrik som är säker på sin presentation oavsett föräldrarna.
Rubrikelement (h1-h6) ska ha exakt en regel på en webbplats.
En förlängning av regeln ovan för att förbättra förutsägbarheten för presentationen. Rätt eller fel, kom ihåg att detta i grunden utesluter inklusive någon form av återställningskod inom ditt stilark. Varje återställningsark fungerar också på dina rubriker och därmed markerar CSSLint det som ett fel.
Angränsande klasser ser ut som .foo.bar. Medan tekniskt tillåtet i CSS hanteras dessa inte korrekt av Internet Explorer 6 och tidigare.
Med denna regel aktiverad, reglerar CSSLint-flaggor som .nav.red, med den officiella orsaken är att Internet Explorer 6 och nedan inte spelar bra med väljaren. Jag respekterar utvecklarna men jag måste vara oense här. Bara för att det inte fungerar med Internet "Dev-buster" Explorer 6 Det är inte en bra anledning att sluta arbeta med en användbar funktion.
Borders och padding lägger till utrymme utanför ett elements innehåll. Inställning av bredd eller höjd längs med gränser och vaddering är vanligtvis ett misstag eftersom du inte får det visuella resultatet du letar efter. CSS Lint varnar när en regel använder bredd eller höjd förutom vaddering och / eller kant.
Boxmodellen kanske bruten, men nästan alla främre utvecklare som jag vet är noggrant medvetna om bristerna och hur man kan övervinna skillnaderna med implementeringen. Är vi verkligen redo att ge upp ett lager av kontroll eftersom vissa äldre webbläsare har en annan implementering?
Användning av webbfonter levereras med prestationseffekter, eftersom fontfiler kan vara ganska stora och vissa webbläsare blockerar rendering medan de laddas ner. Av denna anledning kommer CSS Lint att varna dig när det finns mer än fem webbfonter i ett stilark.
Jag förutser inte en situation där jag skulle använda mer än fem typsnitt på en sida men jag tycker att det är lite tvivelaktigt att doppa in i detta område. Om något är detta en designfel än en utvecklingsfel. Om en utvecklare hänvisar till fem separata teckensnitt i hans stilark är chansen att det inte är en slump.
CSS Lint kontrollerar enkelt för att se om du har använt float mer än 10 gånger, och i så fall visar en varning. Med hjälp av detta betyder många flottor vanligtvis att du behöver någon form av abstraktion för att uppnå layouten.
Medan jag instämmer med skaparens argument att det är en dålig idé att ha mer än tio instanser av flottör, känner jag också att detta kommer att påverka markeringen en gång över en viss storlek.
Till exempel, i en situation där du vill flyta två element, brukar du använda:
? och styling, med traditionella metoder.
.behållare-1 bredd: 70%; flyta till vänster; .container-2 width: 30%; flyta till vänster;
CSSLint-metoden skulle abstrahera flottören som så:
? och styling som så:
.behållare-1 bredd: 70%; .container-2 width: 30%; .flot float: left;
Medan jag håller med om att detta är ett livskraftigt tillvägagångssätt, känner jag mig att märket kommer att bli betydligt trångt när du försöker abstradera mer bort. Jag skulle hellre se en klass som innehåller merparten av sin styling på ett ställe än att röra markeringen med 10+ klasser. Återigen anser jag att detta är ett subjektivt ämne.
Alla ovanstående regler följer de nuvarande standardpraxiserna. Visst, några av reglerna har liten verklig världsbetydelse, som nollvärden som inte behöver enheter, eller kommer att fångas av en anständig IDE, som att analysera fel, men ändå är det goda regler att ha i ett CSS testpaket.
CSSLint kommer att hjälpa många utvecklare på vägen men?
CSSLint är utan tvekan skrivet av utvecklare med bra referenser och kommer definitivt att hjälpa många utvecklare och designers på vägen.
Vad jag tycker är lite irriterande är att många av de kontroversiella reglerna kommer från Objektorienterad CSS, en CSS-ram som syftar till att låta utvecklare skriva underhållsbar CSS. Medan jag inte har något emot ramverket och dess paradigm, måste du hålla med om att det är ett sätt att göra saker, inte de sätt att göra saker.
I motsats till JSLint där jag känner att alla reglerna är klara, med CSSLint känns det som att jag får höra att en typ av skrivning CSS är rätt och de andra är felaktiga. Det skulle vara som någon som frågar mig att ge upp Beatles eftersom Rolling Stones är deras favoritband.
Verktyg är bara det - verktyg.
Självklart tenderar vi som grupp att vara ganska klamiga när det gäller vår kod. Vi tycker inte om att höra att vår kod skulle kunna * hysa * potentiella problem eller skrivas på ett helt annat sätt.
Det viktigaste att notera här är att CSSLint är i sista hand ett verktyg. Det låter dig bara veta att några av områdena Maj har fel.
CSSLint behöver inte vara järnnäven runt vilken du baserar hela ditt ego på. Det finns ingen anledning att böja bakåt för att undvika en varning om du vet exakt vad du gör.
Ja.
I CSS, som i integralkalkyl, finns det många lösningar på ett givet problem. Det är nödvändigtvis inte ett "bästa" sätt att göra saker - du kan gynna läsbarhet medan jag kan gynna effektivitet. Vad som är viktigt är att du inser att var och en av oss har vårt unika sätt att göra saker.
Om du inte har samma perspektiv för att lösa ett problem, kan du vara oense med ett annat tillvägagångssätt och kan även hitta det ifrågasättande.
Med detta sagt finns det aldrig en bra anledning att inte lära sig nya saker. Titta på problem ur ett annat utvecklingsperspektiv är ett bra sätt att se om du kan lära dig något nytt.
Vad tycker du om CSSLint? Hitta det användbart? Förvirrande? Har det hjälpt med dina verkliga problem? Låt oss veta i kommentarerna.
Var utmärkt för varandra och tack så mycket för att läsa!
Accentsconagua