Share
Det er mange ressurser vi kan lene på under kodingen som vil bidra til å bevare standarder over hele laget. I denne opplæringen skal vi se på hvordan du distribuerer og bruker fem av disse verktøyene.
HTML, CSS og JavaScript er spesielt lett å gå hvor spørsmålet om å skrive konvensjoner er bekymret. Så lenge visse notater følger språkreglene, at anførselstegn, parenteser, kolonner, halvkolonner og så videre er på riktig sted, vil koden fungere. Innrykk, mellomrom, linjebrytende, deklarasjonsordre av egenskaper, funksjoner og variabler, inkludert deres ordforankring, er helt opp til forfatterne.
HTML-elementer, for eksempel, er ikke egentlig saksfølsomme. Vi kan skrive dem små eller store bokstaver; hva var en vanlig praksis tilbake på 90-tallet. I tillegg har innpakningsattributtverdier i sitater vært valgfrie siden ankomsten av HTML5, noe få folk faktisk gjør. Alt dette gjør at koden nedenfor kan deklareres gyldig per HTML5-standarden:
/ ** Valid HTML i HTML ** /Innholdet går foran design. Design i fravær av innhold er ikke design, det er dekorasjon.
I CSS, foretrekker noen å bruke rom over tab-eller omvendt-for innrykk. Egenskaper innenfor stilregler kan ordnes i hvilken som helst rekkefølge. Tilstedeværelsen av duplikater i CSS er helt greit (mesteparten av tiden), og i tilfelle av CSS Pre-prosessorer er overdreven nesting av stilregler helt gjennomførbare.
.nettsted .header & .logo .navigering .menu .menu-link &: hover
På samme måte kan en JavaScript-variabel uttrykkes med store eller små bokstaver, en enkelt bokstavsvariabel er akseptabel, og det er også mulig å utelate braces rundt betingede eller loopblokker..
if (n < 3) doFunction(); while(!n < 3) n++;
Måten vi skriver kode på, betyr egentlig ikke så mye med hensyn til gjennomføring. Men når du jobber med et prosjekt med mange som bidrar til kodebase, du vil snart finne kodebase bli et rot hvis hver bidragsyter følger deres egen preferanse. På et stort prosjekt kan det føre til kompliserte feil, koden kan bli mindre håndterbar og ville være en reell smerte for alle som arver og opprettholder prosjektet i fremtiden..
Kort sagt, det oppfordres til å vedta en "kodningsstandard".
"Koding Standarder" er et sett av regler som er avtalt av de involverte, når de bidrar til prosjektkoden. De bane standarden for syntaxing for å opprettholde konsistens og klarhet i koden, formatering for lesbarhet, bruk av felles beste praksis av språket; ofte med noen tillegg av proprietære regler som er unike for prosjektet.
Harry Roberts, i sin CSS Retningslinjer:
"Ved å jobbe på store, langsiktige prosjekter, med dusinvis av utviklere av ulike spesialiteter og evner, er det viktig at vi alle jobber på en enhetlig måte for blant annet å holde stilarkene vedlikeholdbare. hold koden gjennomsiktig, sane og lesbar, hold stilarkene skalerbare; "
Douglas Crockford, som populariserte JSON i sin "Code Conventions for JavaScript Programming Language" uttalt:
"Den langsiktige verdien av programvare til en organisasjon er i direkte forhold til kvaliteten på kodebasen. I løpet av sin levetid vil et program bli håndtert av mange par hender og øyne. Hvis et program er i stand til å klart kommunisere sin struktur og egenskaper, er det mindre sannsynlig at det vil bryte når det endres i den altfor fjerne fremtid. Kodekonvensjoner kan bidra til å redusere brittleness av programmer.
All vår JavaScript-kode sendes direkte til publikum. Det skal alltid være av publikasjonskvalitet. Neatness teller. "
Det korte svaret er "ikke nødvendigvis", spesielt med tanke på at det allerede finnes dusinvis av vanlige stilførere i naturen, for eksempel:
Disse stilguider er godt skrevet, i dybden og ganske selvforklarende når det gjelder begrunnelsen bak hver regel de påvirker. Så, i stedet for å komponere vår egen stilguide, kan det være klokere å adoptere og tilpasse seg eksisterende mønstre for å passe det inn i prosjektet med en gang.
Det virkelige spørsmålet nå er hvordan vi holder alle som følger de standardene vi velger?
Heldigvis er det et par ressurser vi kan lene på under utviklingsprosessen som vil bidra til å bevare standarder over hele laget. I denne opplæringen skal vi se på hvordan du distribuerer og bruker noen av disse verktøyene.
EditorConfig er en dot-fil som registrerer noen grunnleggende formateringsregler som innrykk, hvite plass og nye linjer som bryter. Det fungerer universelt for alle typer språk og er allerede integrert i nesten alle kodeditorer og IDEer som Visual Studio, Sublime Text, Vim og TextMate via plugins.
Forutsatt at du bruker Sublime Text, er den enkleste måten å installere pluginet gjennom Package.
Accentsconagua
.editorconfig i rotkatalogen av prosjektet som vil anvende de angitte konfigurasjonene gjennom alle filene, inkludert de i underkatalogene.root = true [*] charset = utf-8 indent_style = fan indent_size = 4 insert_final_newline = true
Gitt konfigurasjonen fra vårt eksempel, finner vi vår kode inntrukket med kategorien, og legger til en ny linje på slutten av filen mens du lagrer den.
Konfigurasjonen vil påvirke alle eksisterende filer der du tidligere har brukt plassinnrykk.
Se Støttede egenskaper for gjeldende egenskaper til .editorconfig fil og EditorConfig Wildcard Patterns å bruke egenskapene for bestemte filer eller kataloger. Du kan også finne listen pluginet til den foretrukne redigereren eller IDE-er i nedlastingsdelen.
I henhold til CodeGuide-retningslinjen, bør stilegenskaper grupperes i henhold til følgende påfølgende rekkefølge.
stilling, topp, venstre, etc.bredde, høyde, vise, etc.font, linjehøyde, etc.bakgrunn, grense, border-radius, etc.For eksempel:
.kroppsinnhold posisjon: absolutt; topp: 0; venstre: 0; polstring: 10px 12px; skjerm: ingen; skriftstørrelse: .8em; font-weight: bold; linjehøyde: 26px; farge: #fff;
Hvis du vedtar en retningslinje med en lignende regel, der egenskaper er gruppert i den bestemte ordren, vil CSSComb virkelig komme til nytte. Ikke bare gjør det det mulig å gjøre akkurat dette, men i tillegg beholder flere stilkonvensjoner som mellomrom, bruk av sitater, braces, kolon, semikolon, ledende null for lengdeverdi, og det fungerer fint med CSS Preprocessor-syntaks.
npm installere csscomb -g .csscomb.json i rotkatalogen av prosjektet, eller i katalogen der CSS-filene er lagret..csscomb.json. Sjekk mot den komplette listen over gjeldende alternativer. For å gjøre det lettere, kan du generere konfigurasjonsfilen via Konfig Builder-webapp, eller bruke noen av de forhåndsinnstilte konfigurasjonene som finnes i depotet.Bruke csscomb kommando, slik som:
csscomb-eiendeler / css / style.css
Hvis du foretrekker det, kan du kjøre CSSComb under byggeprosessen med Gulp eller Grunt-plugin. Alternativt kan du bruke et plugin i kodeditoren som Sublime Text og kjøre den gjennom Kommandopaletten. Det er også et plugin tilgjengelig for Brackets og Atom.
StyleLint er et verktøy som undersøker vårt CSS mot mer enn hundre forhåndsdefinerte regler, og produserer advarsler ved brudd. Noen av disse bruddene er enkle å fikse med CSSComb, noe som gjør disse verktøyene gode å bruke hånd i hånd. CSSLint er også et perfekt verktøy for å utføre en kodeanmeldelse.
npm installer stylelint -g .stylelintrc fil i rotkatalogen av prosjektet ditt..stylelintrc fil, for eksempel:"rules": "color-hex-case": "lavere", "farge-hex-lengde": "short", "comment-empty-line-before": "alltid", "selector-no-combinator ": true," selector-no-id ": true," string-quotes ":" double "," selector-no-type ": true," selector-no-universal ": true," selger-no-vendor -prefix ": true
En fullstendig liste over gjeldende Stylint-regler finner du på Regelsiden.
Bruk Stylelint gjennom kommandolinjen (f.eks: stylet "css / *. css"), PostCSS med pluginet, eller installer et plugin som lar deg se advarslene direkte i kodeditoren din. Pluggen er for øyeblikket tilgjengelig for Sublime Text, Atom og Visual Studio.
Som navnet antyder, evaluerer JSCS JavaScript-kodestiler; fra bruk av hvite plass, funksjoner og variabel navngivningskonvensjoner, kommentatorblokker, linjeskift og mye mer. JSCS har blitt brukt mye i populære open source-prosjekter som jQuery, Bootstrap og Ember.js, og også av bemerkelsesverdige selskaper som Yandex og Adobe. Testamentet virkelig; du bør sannsynligvis bruke den i prosjektet ditt også!
npm installere jscs -g..jscsrc."JQuery", "airbnb", "Google", "Yandex", og "Wordpress"."forhåndsinnstilt": "wordpress", "requireCurlyBraces": true
Forutsatt at JavaScript-filen din er lagret i JS / app.js, Kjør kommandoen: jscs js / app.js.
For å fikse kodestiler, kjør jscs js / app.js --fix. I Sublime Text kan du installere JSCS Formatter for å gjøre det uten å forlate kodeditoren. En lignende plugin som heter JSCS Fixer er også tilgjengelig for Atom.
Et annet verktøy som jeg bruker daglig for å sjekke JavaScript er JSHint. I motsetning til JSCS dreier JSHint-evalueringer rundt kodevaliditet, i stedet for bare kodestilen. I tillegg vil JSHint også fjerne stilistiske Regler i neste utgave, siden JSCS har vært økende trekkraft og gjør jobben bra på det aktuelle saken. Som sådan vil JSHint bare sjekke bruken av variabler, looper, sammenligningsoperatører, scopes, nesting level og lignende andre tekniske JavaScript ting som muligens forårsaker problemer eller feil.
npm installere jshint -g .jshintrc i rotkatalogen av prosjektet ditt..jshintrc, for eksempel:"sjef": sant, "eqeqeq": sant, "eqnull": sant, "expr": sant, "immed": sant, "noarg": sant, "undef": sant, "ubrukt" node ": true
Bruke jshint kommandolinje. Forutsatt at du har alle JavaScript-filene dine lagret i en katalog som heter js, løpe jshint js.
Alternativt kan du bruke JSHint med pluggen Gulp eller Grunt. Sublim Tekst- eller Atom-brukere kan installere lintergrensesnitt for SublimeText, Atom, slik at du kan se feilrapporten direkte i kodeditoren.
Tips: CodePen vil også sjekke JavaScript for feil ved bruk av JSHint; finn dette alternativet i JavaScript-innstillinger-panelet:
Hvis innstillingen av alle disse verktøyene på prosjektet ditt kan virke kjedelig, bruk Yeoman å sette dem sammen som et stillas. Når du eller teamet ditt er i ferd med å starte et nytt prosjekt, trenger du bare å treffe en enkeltkommando for å få dem klar om et par sekunder. For mer informasjon, følg Envato Tuts + kurset om hvordan du oppretter en tilpasset Yeoman Generator.
Til slutt, å ha disse verktøyene vil ikke bare hjelpe oss med å produsere bedre kode og minimere feil i koden vår, men de vil trene oss til å være bedre webutviklere. Først kan du finne at koden din har mange feil. Men du vil snart skrive kode med færre feil, ettersom du begynner å bli vant til reglene.
