Share
Er zijn talloze bronnen waarop we kunnen leunen tijdens het coderen, zodat de normen binnen het hele team behouden blijven. In deze zelfstudie gaan we kijken hoe we vijf van deze hulpprogramma's kunnen implementeren en gebruiken.
HTML, CSS en JavaScript zijn bijzonder gemakkelijk, waar het gaat om schrijven conventies maakt zich zorgen. Zolang bepaalde notaties de taalregels volgen, dat de aanhalingstekens, haakjes, dubbele punten, puntkomma's enzovoort allemaal op de juiste plaats staan, zal de code werken. Indrukken, spaties, lijnbreuken, declaratie-volgorde van eigenschappen, functies en variabelen, inclusief hun woordomhulling, zijn echter geheel aan de auteurs.
HTML-elementen zijn bijvoorbeeld niet hoofdlettergevoelig. We kunnen ze in kleine letters of in hoofdletters schrijven; wat gebruikelijk was in de jaren 90. Bovendien is het wikkelen van kenmerkwaarden tussen aanhalingstekens optioneel geweest sinds de komst van HTML5, iets wat maar weinig mensen daadwerkelijk doen. Hiermee kan de onderstaande code worden gedeclareerd Geldig volgens de HTML5-standaard:
/ ** Geldige HTML in HTML ** /Inhoud gaat vooraf aan het ontwerp. Ontwerpen in afwezigheid van inhoud is geen ontwerp, het is decoratie.
In CSS geven sommigen de voorkeur aan gebruik ruimte over- tab-of vice versa - voor inspringen. Eigenschappen binnen stijlregels kunnen in elke volgorde worden gerangschikt. De aanwezigheid van duplicaten in je CSS is prima (meestal), en in het geval van CSS Pre-processors is overmatig nesten van stijlregels perfect uitvoerbaar.
.site .header & .logo .navigation .menu .menu-link &: hover
Evenzo kan een JavaScript-variabele worden uitgedrukt met hoofdletters of kleine letters, een variabele van één letter is aanvaardbaar en het weglaten van accolades rond voorwaardelijke of lusblokken is ook werkbaar.
if (n < 3) doFunction(); while(!n < 3) n++;
De manier waarop we code schrijven maakt eigenlijk niet zo veel uit in termen van uitvoering. Maar als je aan een project werkt met veel mensen die bijdragen aan de codebasis, je zult snel merken dat de codebasis een puinhoop wordt als elke bijdrager zijn eigen voorkeur volgt. Op een grootschalig project kan dit ingewikkelde bugs veroorzaken, kan de code minder beheersbaar worden en zou het echt lastig zijn voor iedereen die het project in de toekomst erft en onderhoudt.
Kort gezegd wordt het aangemoedigd om een "coderingsstandaard" te gebruiken.
"Codeerstandaarden" zijn alle regels die door de betrokkenen zijn overeengekomen bij het bijdragen aan de basis van de projectcode. Ze zetten de standaard voor syntaxing om de consistentie en duidelijkheid van de code te behouden, de opmaak voor leesbaarheid, het gebruik van gemeenschappelijk beste praktijken van de taal; vaak met toevoeging van eigen regels die uniek zijn voor het project.
Harry Roberts, in zijn CSS-richtlijnen:
"Bij het werken aan grote, langlopende projecten, met tientallen ontwikkelaars met verschillende specialiteiten en capaciteiten, is het belangrijk dat we allemaal op een uniforme manier werken om onder andere stylesheets onderhoudbaar te houden; houd code transparant, gezond en leesbaar, houd stylesheets schaalbaar; "
Douglas Crockford, die JSON populair maakte in zijn "Code-conventies voor de JavaScript programmeertaal", verklaarde:
"De waarde van software voor de lange termijn voor een organisatie staat in directe verhouding tot de kwaliteit van de codebasis. Gedurende zijn levensduur zal een programma worden behandeld door vele paren van handen en ogen. Als een programma in staat is om de structuur en kenmerken duidelijk te communiceren, is het minder waarschijnlijk dat het zal breken wanneer het in de nooit te verre toekomst wordt gewijzigd. Code-conventies kunnen helpen de broosheid van programma's te verminderen.
Al onze JavaScript-code wordt rechtstreeks naar het publiek verzonden. Het moet altijd van publicatiekwaliteit zijn. Neatness telt. "
Het korte antwoord is "niet noodzakelijkerwijs", vooral omdat er al tientallen veelgebruikte stijlgidsen in het wild bestaan, bijvoorbeeld:
Deze stijlgidsen zijn goed geschreven, diepgaand en vrij vanzelfsprekend in termen van de redenering achter elke regel die ze beïnvloeden. Dus, in plaats van het samenstellen van onze eigen stijlgids, is het misschien verstandiger om dit te doen adopteren en aanpassen bestaande patronen om meteen in ons project te passen.
De echte vraag is nu hoe we ervoor zorgen dat iedereen de normen volgt die we kiezen?
Gelukkig zijn er een aantal middelen waarop we kunnen leunen tijdens het ontwikkelingsproces, zodat we de normen binnen het hele team kunnen behouden. In deze zelfstudie gaan we kijken hoe we sommige van deze hulpprogramma's kunnen implementeren en gebruiken.
EditorConfig is een puntbestand dat een aantal basisopmaakregels registreert, zoals de inspringing, witruimte en het breken van nieuwe regels. Het werkt universeel voor elk type taal en is al geïntegreerd in bijna alle code-editors en IDE's zoals Visual Studio, Sublime Text, Vim en TextMate via plug-ins.
Ervan uitgaande dat u Sublime Text gebruikt, is de eenvoudigste manier om de plug-in te installeren via de Pakket manager.
Accentsconagua
.editorconfig in de hoofdmap van het project dat de opgegeven configuraties toepast via alle bestanden, inclusief bestanden in de submappen.root = true [*] charset = utf-8 indent_style = tab indent_size = 4 insert_final_newline = true
Toegegeven de configuratie van ons voorbeeld, we zullen onze code ingesprongen vinden met een tab en een nieuwe regel toevoegen aan het einde van het bestand terwijl je het opslaat.
De configuratie is van invloed op alle bestaande bestanden waarin u eerder inspringen van spaties hebt gebruikt.
Raadpleeg Ondersteunde eigenschappen voor toepasselijke eigenschappen voor de .editorconfig bestand en de EditorConfig-jokertekens om de eigenschappen voor specifieke bestanden of mappen toe te passen. Je kunt ook een lijst vinden van de plug-in van je favoriete editor of IDE's in de downloadsectie.
Volgens de CodeGuide-richtlijn moeten stijleigenschappen worden gegroepeerd in overeenstemming met de volgende opeenvolgende volgorde.
positie, top, links, enz.breedte, hoogte, tonen, enz.doopvont, lijnhoogte, enz.achtergrond, grens, border-radius, enz.Bijvoorbeeld:
.body-inhoud positie: absoluut; boven: 0; links: 0; opvulling: 10px 12px; Geen weergeven; lettertypegrootte: .8em; lettertype: vet; regelhoogte: 26px; kleur: #fff;
Als u een richtlijn met een vergelijkbare regel toepast, waarin eigenschappen in die bepaalde volgorde zijn gegroepeerd, zal CSSComb echt van pas komen. Niet alleen staat het je toe om precies dit te doen, maar bovendien behoudt het verschillende stijlconventies zoals spatiëring, het gebruik van aanhalingstekens, accolades, dubbele punten, puntkomma's, nul voor lengtewaarde, en het werkt mooi met CSS Pre-processor syntaxis.
npm installeer csscomb -g .csscomb.json in de hoofdmap van het project, of in de map waar de CSS-bestanden zijn opgeslagen..csscomb.json. Controleer tegen de volledige lijst met toepasselijke opties. Om het eenvoudiger te maken, kunt u het configuratiebestand genereren via de Config Builder-webapp of een van de vooraf ingestelde configuraties gebruiken die u in de repository kunt vinden.Gebruik de csscomb commando, zoals zo:
csscomb assets / css / style.css
Als u wilt, kunt u CSSComb uitvoeren tijdens het buildproces met de Gulp- of Grunt-plug-in. Als alternatief kunt u een plug-in in uw code-editor zoals Sublime Text gebruiken en deze doorlopen Opdrachtpalet. Er is ook een plug-in beschikbaar voor Brackets en Atom.
StyleLint is een tool die onze CSS onderzoekt tegen meer dan honderd vooraf gedefinieerde regels, waarbij waarschuwingen worden geproduceerd in geval van overtredingen. Sommige van deze schendingen zijn gemakkelijk te repareren met de CSSComb, waardoor deze gereedschappen geweldig zijn om hand in hand te gebruiken. CSSLint is ook een perfect hulpmiddel om een codebeoordeling uit te voeren.
npm install stylelint -g .stylelintrc bestand in de hoofdmap van uw project..stylelintrc bestand, bijvoorbeeld:"rules": "color-hex-case": "lower", "color-hex-length": "short", "comment-empty-line-before": "always", "selector-no-combinator ": true," selector-no-id ": true," string-quotes ":" double "," selector-no-type ": true," selector-no-universal ": true," selector-no-vendor " -prefix ": true
Een volledige lijst met toepasselijke Stylint-regels is te vinden op de pagina Regels.
Gebruik Stylelint via de opdrachtregel (bijv .: stylelint "css / *. css"), PostCSS met de plug-in of installeer een plug-in waarmee u de waarschuwingen direct in uw code-editor kunt zien. De plug-in is momenteel beschikbaar voor Sublime Text, Atom en Visual Studio.
Zoals de naam al aangeeft, evalueert JSCS uw JavaScript-codestijlen; van het gebruik van witruimte, functies en variabele naamgevingsconventies, commentaarblokken, regeleinden en nog veel meer. JSCS is op grote schaal gebruikt in populaire open-sourceprojecten zoals jQuery, Bootstrap en Ember.js, en ook door opmerkelijke bedrijven zoals Yandex en Adobe. Testament inderdaad; je zou het waarschijnlijk ook in je project moeten gebruiken!
npm jscs -g installeren..jscsrc."JQuery", "Airbnb", "Google", "Yandex", en "Wordpress"."preset": "wordpress", "requireCurlyBraces": true
Ervan uitgaande dat uw JavaScript-bestand is opgeslagen in js / app.js, voer het commando uit: jscs js / app.js.
Om de codestijlen te repareren, voert u uit jscs js / app.js --fix. In Sublime Text kun je JSCS Formatter installeren om dit te doen zonder de code-editor te verlaten. Een vergelijkbare plug-in genaamd JSCS Fixer is ook beschikbaar voor Atom.
Een ander hulpmiddel dat ik dagelijks gebruik om mijn JavaScript te controleren, is JSHint. In tegenstelling tot JSCS, hebben JSHint-evaluaties betrekking op codegeldigheid in plaats van alleen de codestijl. Bovendien zal JSHint ook verwijderen stilistisch regels in de volgende release, omdat JSCS tractie heeft ontwikkeld en het werk goed doet met die specifieke kwestie. Als zodanig controleert JSHint alleen tegen het gebruik van variabelen, loops, vergelijkingsoperatoren, scopes, nestingsniveau en andere technische JavaScript-zaken die mogelijk problemen of bugs veroorzaken..
npm jshint -g installeren .jshintrc in de hoofdmap van uw project..jshintrc, bijvoorbeeld:"boss": true, "eqeqeq": true, "eqnull": true, "expr": true, "immed": true, "noarg": true, "undef": true, "unused": true, " knooppunt ": true
Gebruik de jshint opdrachtregel. Ervan uitgaande dat u al uw JavaScript-bestanden hebt opgeslagen in een map met de naam js, rennen jshint js.
Gebruik alternatief JSHint met de Gulp- of Grunt-plug-in. Sublime Text- of Atom-gebruikers kunnen het linter interface voor SublimeText, Atom, zodat u het foutrapport rechtstreeks in de codebewerker kunt zien.
Tip: CodePen controleert ook uw JavaScript op fouten met behulp van JSHint; zoek deze optie in het paneel JavaScript-instellingen:
Als het instellen van al deze tools op uw project saai lijkt, kunt u Yeoman gebruiken om ze als een steiger samen te stellen. Wanneer u of uw team op het punt staat een nieuw project te starten, hoeft u slechts één regelopdracht te gebruiken om ze binnen een paar seconden klaar te maken. Volg voor meer informatie de Envato Tuts + -cursus over het maken van een aangepaste Yeoman-generator.
Ten slotte helpen deze tools niet alleen ons om betere code te produceren en fouten in onze code te minimaliseren, maar zullen ze ons ook opleiden tot betere webontwikkelaars. In het begin kunt u merken dat uw code veel fouten bevat. Maar je zult snel code schrijven met minder fouten, als je begint te wennen aan de regels.
