Share
Spesielt når man først begynner med ulike webutviklingsspråk, kan det vise seg å være en vanskelig oppgave å lære alle de forskjellige navngivningskonvensjonene fra språk til språk. Dette kan være enda mer forvirrende når utviklerne er uenige om hva som vurderes beste praksis. For å lette overgangen for nybegynnere, vil denne listen beskrive noen av de mer vanlige konvensjonene.
Når du kommer over en variabel eller metode som fortsetter med en _, Det er ingen voodoo magi som blir utført bak kulissene. Det er bare en navngivningskonvensjon som påminner utvikleren om at variabelen / egenskapen / metoden er enten privat eller beskyttet, og kan ikke nås utenfor klassen.
// Denne variabelen er ikke tilgjengelig utenfor klassen privat $ _someVariable; klasse MyClass // Denne metoden er bare tilgjengelig fra denne klassen, eller // andre som arver fra den. beskyttet funksjon __behindTheScenesMethod ()
Legg merke til at understreket i koden ovenfor ikke er hva gjør at variabelen eller metoden privat; de privat / beskyttet søkeord gjør det. Understreket er bare en påminnelse i seks måneder nedover veien!
var Person = (funksjon () var _trueAge = 50, _trueWeight = 140; tilbake alder: _trueAge - 15, vekt: _trueWeight - 30;) (); Person.age; // 35 Person.weight; // 110 Person._trueAge; // undefined (fordi det er privat, yo)
Ved å lage Person lik, ikke en funksjon, men den returnerte gjenstand, Vi kan lage private variabler. Igjen, understreket prefixet minner oss om dette.
EN konstant er en variabel med en statisk verdi, som ikke vil endre seg. For eksempel, hvis prosjektet ditt krevde behovet for å multiplisere en verdi av statsskatten, kan du tildele denne satsen, $ 0,0825 til en konstant. Men ikke alle språk har disse variablene bygget inn. Som sådan er det en god praksis å bruke alle store bokstaver for å minne deg på at du jobber med en konstant. Dette er en vanlig konvensjon i JavaScript-verdenen, og brukes til sine opprinnelige objekter, som MATH.PI.
var TAXRATE = .0825;
Accentsconagua
define ('TAXRATE', .0825); Du har sikkert, på et tidspunkt, kommet over en variabel som ble videreført med et enkelt brev, for eksempel "S" eller "Jeg".
$ sName = 'Kaptein Jack Sparrow';
Dette kalles Ungarsk notasjon, og har falt ut av favør de siste årene, selv om det fortsatt er en konvensjon som brukes av mange selskaper.
Ungarsk notat er en navngivningskonvensjon som minner utvikleren om
typeav variabel som han jobber med:sTring,Jegnteger, etc.
Spesielt i JavaScript-verdenen, er denne praksisen frowned på, på grunn av det faktum at det er et løst skrevet språk. Et løst skrevet språk er en som ikke krever at du erklærer datatypen til en variabel. Hvorfor er det viktig? Hva om, ved å bruke notasjonskonvensjonen ovenfor, erklærte vi en streng med "S" prefiks, men senere endret variabelen til et heltall? På den tiden ville denne form for notasjon faktisk fungere mot oss, ikke for oss.
var sName = "Lieutenant Commander Geordi La Forge"; typeof (sName); // streng ... sName = undefined; typeof (sName) // undefined
Brukere av jQuery: Før du går på sokkelen og roser deg for ikke å bruke denne form for notasjon, spør deg om du har prefiksetvariabler - innpakket i jQuery-objektet - med et dollar-symbol? Hvis ja, det er en form for ungarsk notasjon. Det er et symbol prefixed til et variabelt navn som tjener det eneste formålet med å informere deg om variabelenes type eller kvaliteter.
// Dollarsymbolet minner meg om at denne variabelen // har tilgang til jQuerys ulike metoder. var $ container = $ ('# container'); Det er helt opp til deg. Selv mange jQuery teammedlemmer bruker dollar prefiks metoden. Til slutt, hvis det virker for deg, det er alt som betyr noe. Personlig, for omtrent et år siden, bruker jeg ikke dollar-symbolet prefiks lenger - men bare fordi jeg skjønte at det ikke var nødvendig for meg. Gjør ditt eget sinn til dette.
Hva med de "variable" navnene, som kapitaliserer første bokstav i navnet?
$ respons = $ SomeClass-> doSomething ();
I koden ovenfor, $ SomeClass er kapitalisert fordi det er a klasse og ikke en variabel Navn. Igjen, dette er en navngivningskonvensjon som de fleste utviklere bruker. Når du kommer tilbake til koden et år senere, er det en liten lyspære som informerer dem om at de jobber med en klasse, som har objekter og metoder tilgjengelig.
// Merk hovedstaden M i klassenavnet. klasse $ MyClass funksjon __construct ()
I JavaScript har vi egentlig ikke klassees; men vi har det konstruktør funksjoner.
var Jeff = ny person ();
Grunnen til at vi kapitaliserer konstruktørens navn (Person) er fordi det kan vise seg lett å noen ganger glemme ny søkeord. Under slike omstendigheter vil JavaScript ikke kaste noen advarsler, og det kan være et mareritt å spore opp glitchen. Kapitaliseringen er et nyttig varsel for utvikleren, når feilsøking. Douglas Crockford er en stor talsmann for denne konvensjonen.
Alternativt, hvis du ønsker å beskytte mot din glemsel, er du i stand til å sikre at konstruktøren faktisk er riktig før du fortsetter.
funksjon Person (navn) // Hvis det nye søkeordet er fraværende, vil konstruktøren være vinduet. // I dette tilfellet kompensere og returnere en ny forekomst hvis (this.constructor! == Person) returner ny person (navn); this.name = navn; // Intentivt glemte det "nye" søkeordet var Joey = Person ('Joey'); Joey.name; // Joey Hvorfor er det at noen variabler bruker et kamel-mønster, mens andre bruker et understreke for å skille ord? Hva er den riktige metoden? Svaret er at det er nei riktig bruk. Det er helt avhengig av språket og / eller bedriftens kodingskonvensjoner. Begge er helt akseptable.
// camelCase var preacherOfSockChanging = 'Lieutenant Dan'; // under_score var preacher_of_sock_changing = 'Lieutenant Dan';
Men med alt sagt er det en god praksis - når du har muligheten - å følge de vanlige konvensjonene i språket du bruker. For eksempel bruker det store flertallet av JavaScript-utviklere camelCase-syntaksen, mens andre språk, som PHP, har en tendens til å foretrekke underskriftsbruken. Selv om dette igjen ikke er satt i stein. Zend Framework fortaler camelCasing som en god praksis.
Mer viktig enn det du bruker, er å sikre at du holder fast ved det!
Spesielt når du jobber på et lag, er det viktig at du vedtar riktig katalogstruktur som medarbeidere. Men i det minste, ikke slipp alle stilarkene dine og skriptene inn i roten av prosjektet ditt, uten noen organisasjon. Mange utviklere foretrekker å plassere alle sine bilder, skript og stilark i en forelder Eiendeler katalog.
/ Prosjektrot / Assets / js / min script_min.js script.js / css / min style_min.css style.css / img img1.jpg index.html otherFile.html
Legg også merke til konvensjonen om å skape en min mappe, som inneholder dynamisk tilførte, minifiserte versjoner av skript og stilark.
Når du oppretter mark-up, forhåpentligvis forstår det allment at ids og klassees du velger bør beskrive innholdstypen, og ikke presentasjonsaspektene. Som et eksempel:
Justin Bieber er min homeboy seksjon.
Justin Bieber er min homeboy seksjon.
Justin Bieber er min homeboy seksjon.
Hvorfor det? Hva hvis du, seks måneder nedover veien, bestemmer deg for å plassere Justin Bieber fan-delen i middel RIGHT-og-deretter-en-litt lavere- seksjon? På det tidspunktet, din id vil gi liten mening.
Når vi overgår til en HTML5-verden, bør du finne deg selv med å bruke langt færre identifikatorer i elementene dine.
ids er mindre fleksible, og er mange ganger unødvendig.
Overskrifts og bunnteksts Du vet hva som stinker? Når du arbeider på et sentrert nettsted som krever flere bakgrunner som strekker seg for hele bredden av vinduet (vanligvis for Overskrift og bunntekst), må du vanligvis pakke inn innholdet slik at det ytre elementet strekker seg, mens det indre elementet kan forbli sentrert.
Ettersom dette er et vanlig problem, er det viktig å vedta en felles konvensjon for å skape nødvendig oppgradering.
Den vanskelige avgjørelsen her er at når du jobber med de nye HTML5-elementene, må du bestemme om du skal plassere bunntekst element på innsiden eller utsiden. Det er fortsatt diskutert, men jeg har en tendens til å føle at det er mer semantisk å plassere det egentlige bunntekst element på innsiden.
divs bør bare brukes når:
Bestem nå om du skal tillate bruk av snarveier i koden din eller ikke. Skrive nøyaktig / ren kode er alltid en kamp av lesbarhet vs. størrelse. Det er derfor viktig at utviklingslag følger de samme kodingsretningslinjene. Å gi to raske eksempler:
var navnet = 'joe'; // vanlig hvis (navn === 'Jeff') alert ("Det er meg"); ellers alert ("Nope"); // ternær (navn === 'Jeff')? varsling ("det er meg"): varsel ("nei"); // Nei && For korthåndte kondensatorer? var getTweets = true; // vanlig hvis (getTweets) alert ('får dem nå'); // Logisk OG // Høyre side vil ikke kjøre, med mindre venstre side er "sant" getTweets && alert ('Få dem nå'); Mange utviklere vil rive på bruken av det logiske OG i dette tilfellet, insisterer på at det begrenser lesbarhet. Dette er absolutt et gyldig argument, men selv populære biblioteker som jQuery gjør stor bruk av denne metoden.
For å gjenta, er de spesifikke konvensjonene du velger, langt mindre viktig enn å sikre at du forblir konsistent med bruken din. Faktisk skriver mange utviklingslag sine egne konvensjonsretningslinjer for nye dev-hyringer. Takk for at du leste!
