Share
Vooral wanneer het voor het eerst met verschillende webontwikkelingstalen begint, kan het een moeilijke taak blijken om alle verschillende naamgevingsconventies van taal tot taal te leren. Dit kan nog verwarrend zijn als ontwikkelaars het niet eens zijn over wat wordt overwogen beste oefening. Om de overgang voor beginners te vergemakkelijken, zal deze lijst enkele van de meer gebruikelijke conventies beschrijven.
Wanneer u een variabele tegenkomt of een methode die wordt uitgevoerd door een _, er wordt geen voodoo-magie achter de schermen uitgevoerd. Het is gewoon een naamgevingsconventie die de ontwikkelaar eraan herinnert dat de variabele / eigenschap / methode dat ook is privaat of beschermde, en is niet toegankelijk van buiten de klas.
// Deze variabele is niet beschikbaar buiten de klasse private $ _someVariable; class MyClass // Deze methode is alleen beschikbaar binnen deze klasse, of // andere die ervan erven. beschermde functie __behindTheScenesMethod ()
Merk op dat in de bovenstaande code het onderstrepingsteken niet is wat merken de variabele of methode privaat; de private / beschermd keyword doet dat. Het onderstrepingsteken is slechts een herinnering voor zes maanden op de weg!
var Person = (function () var _trueAge = 50, _trueWeight = 140; return age: _trueAge - 15, weight: _trueWeight - 30;) (); Personage; // 35 Person.weight; // 110 Person._trueAge; // undefined (want het is privé, yo)
Door het maken van Persoon gelijk aan, niet een functie, maar de geretourneerde voorwerp, we kunnen privévariabelen maken. Nogmaals, het onderstrepingvoorvoegsel herinnert ons hieraan.
EEN constante is een variabele met een statische waarde, die niet zal veranderen. Als uw project bijvoorbeeld de noodzaak vereist om een waarde te vermenigvuldigen met de belasting, kunt u deze koers toewijzen, $ 0,0825 naar een constante. Niet alle talen hebben deze variabele typen ingebouwd. Het is daarom een goede gewoonte om alle hoofdletters te gebruiken om u eraan te herinneren dat u met een constante. Dit is een veel voorkomende conventie in de JavaScript-wereld en wordt gebruikt voor de oorspronkelijke objecten, zoals Math.PI.
var TAXRATE = .0825;
Accentsconagua
define ('TAXRATE', .0825); Je bent zeker op een gegeven moment een variabele tegengekomen die werd voortgezet met een enkele letter, zoals "S" of "ik".
$ sName = 'Captain Jack Sparrow';
Dit wordt aangeduid als Hongaarse notatie, en is de afgelopen jaren uit de gratie geraakt, hoewel het nog steeds een conventie is die door veel bedrijven wordt gebruikt.
De Hongaarse notatie is een naamgevingsconventie die de ontwikkelaar herinnert aan de
typevan variabele waarmee hij werkt:sTring,iknteger, enz.
Vooral in de JavaScript-wereld wordt deze praktijk afgekeurd vanwege het feit dat het een losjes getypte taal is. Een losjes getypte taal is een taal die niet vereist dat u het gegevenstype van een variabele declareert. Waarom is dat belangrijk? Wat als we, met behulp van de notatieconventie hierboven, een string met de "S" prefix, maar later veranderde de variabele naar een integer? Op dat moment zou deze vorm van notatie feitelijk tegen ons werken, niet voor ons.
var sName = "Lieutenant Commander Geordi La Forge"; typeof (sName); // string ... sName = undefined; typeof (sName) // undefined
jQuery-gebruikers: voordat je op je voetstuk stapt en jezelf aanprijst omdat je deze notatievorm niet gebruikt, vraag jezelf dan af of je variabelen - ingepakt in het jQuery-object - invoegt met een dollarsymbool? Als dat zo is, is dat een vorm van Hongaarse notatie. Het is een symbool dat voorafgaat aan een variabelenaam en dat alleen bedoeld is om u te informeren over het type of de kwaliteiten van de variabele.
// Het dollarsymbool herinnert me eraan dat deze variabele // toegang heeft tot de verschillende methoden van jQuery. var $ container = $ ('# container'); Dat is helemaal aan jou. Zelfs veel jQuery-teamleden gebruiken de dollarprefix-methode. Uiteindelijk, als het voor u werkt, is dat het enige dat telt. Persoonlijk, vanaf ongeveer een jaar geleden, gebruik ik het voorvoegsel van het dollarteken niet langer - maar alleen omdat ik me realiseerde dat het niet nodig was voor mij. Maak hier je eigen mening over.
Hoe zit het met die "variabele" namen, die de eerste letter van de naam kapitaliseren?
$ response = $ SomeClass-> doSomething ();
In de bovenstaande code, $ SomeClass wordt met een hoofdletter geschreven omdat het een is klasse en niet een veranderlijk naam. Nogmaals, dit is een naamgevingsconventie die de meeste ontwikkelaars gebruiken. Wanneer je een jaar later terugkeert naar de code, is het een klein bedrag gloeilamp die hen informeert dat ze met een klasse werken, die objecten en methoden beschikbaar heeft.
// Let op de hoofdletter M in de klassenaam. class $ MyClass function __construct ()
In JavaScript hebben we niet echt klassees; maar dat hebben we wel bouwer functies.
var Jeff = new Person ();
De reden waarom we de naam van de constructor kapitaliseren (Persoon) is omdat het gemakkelijk kan blijken om soms de nieuwe trefwoord. Onder deze omstandigheden gooit JavaScript geen waarschuwingen en kan het een nachtmerrie zijn om de storing op te sporen. Het hoofdlettergebruik is een nuttige waarschuwing voor de ontwikkelaar bij het debuggen. Douglas Crockford is een groot voorstander van deze conventie.
Als alternatief, als je je wilt beschermen tegen de vergeetachtigheid van je toekomstige zelf, zou je eerst kunnen zorgen dat de constructeur in feite juist is, voordat je verdergaat.
function Person (name) // Als het nieuwe sleutelwoord afwezig is, zal de constructor het venster zijn. // In dit geval, compenseer en retourneer een nieuwe instantie als (this.constructor! == Person) return new Person (name); this.name = naam; // Opzettelijk het "nieuwe" sleutelwoord vergeten var Joey = Persoon ('Joey'); Joey.name; // Joey Waarom gebruiken sommige variabelen een camelCase-patroon, terwijl anderen een onderstrepingsteken gebruiken om woorden van elkaar te scheiden? Wat is de juiste methode? Het antwoord is dat er geen is correct gebruik. Het is volledig afhankelijk van de taal en / of de codeerconventies van uw bedrijf. Beide zijn perfect acceptabel.
// camelCase var preacherOfSockChanging = 'Lieutenant Dan'; // under_score var preacher_of_sock_changing = 'Lieutenant Dan';
Maar met al het bovenstaande is het een goede gewoonte om - als u de optie hebt - de gebruikelijke conventies van de taal die u gebruikt te volgen. De overgrote meerderheid van de JavaScript-ontwikkelaars gebruiken bijvoorbeeld de camelCase-syntaxis, terwijl andere talen, zoals PHP, de voorkeur geven aan het onderstreepte gebruik. Hoewel, nogmaals, dit is niet in steen gebeiteld. Het Zend Framework pleit voor camelCasing als een best practice.
Belangrijker dan wat je gebruikt, is ervoor zorgen dat je je eraan houdt!
Vooral wanneer je aan een team werkt, is het essentieel dat je de juiste directorystructuur aanneemt als je mede-ontwikkelaars. Maar laat in elk geval niet al uw stylesheets en scripts in de root van uw project vallen, zonder enige organisatie. Veel ontwikkelaars geven er de voorkeur aan om al hun afbeeldingen, scripts en stylesheets binnen een ouder te plaatsen Middelen directory.
/ Projectroot / Activa / js / min script_min.js script.js / css / min style_min.css style.css / img img1.jpg index.html otherFile.html
Let ook op de conventie om ook een min map, die de dynamisch toegevoegde, verkleinde versies van uw scripts en stylesheets bevat.
Bij het maken van mark-up, hopelijk is het algemeen begrepen dat de ID kaarts en klassees die u kiest, moet het type inhoud beschrijven, en niet de presentatieaspecten. Als voorbeeld:
Justin Bieber is mijn homeboysectie.
Justin Bieber is mijn homeboysectie.
Justin Bieber is mijn homeboysectie.
Hoe kan dat? Wat als, zes maanden verder, je besluit om je Justin Bieber-fansectie te plaatsen in de Midden-RIGHT-en-dan-een-klein-klein sectie? Op dat moment, jouw ID kaart zal weinig zin hebben.
Naarmate we overstappen naar een HTML5-wereld, zou je merken dat je veel minder identifiers in je elementen gebruikt.
ID kaarts zijn minder flexibel en zijn vele malen onnodig.
hoofds en footers Weet je wat stinkt? Bij het werken aan een gecentreerde website waarvoor meerdere achtergronden nodig zijn die zich over de gehele breedte van het venster uitstrekken (meestal voor de hoofd en footer), moet je meestal je inhoud inpakken zodat het buitenste element zich zal uitstrekken, terwijl het binnenste element gecentreerd kan blijven.
Omdat dit een veelvoorkomend probleem is, is het belangrijk om een gemeenschappelijke afspraak te maken voor het creëren van de noodzakelijke mark-up.
De moeilijke beslissing hier is dat, ervan uitgaande dat je met de nieuwe HTML5-elementen werkt, je moet beslissen of je de footer element aan de binnenkant of de buitenkant. Het is nog steeds ter discussie, maar ik heb de neiging om te voelen dat het semantischer is om het echte te plaatsen footer element aan de binnenkant.
divs mag alleen worden gebruikt als:
Besluit nu of u het gebruik van snelkoppelingen in uw code al dan niet wilt toestaan. Het schrijven van nauwkeurige / schone code is altijd een gevecht van leesbaarheid versus grootte. Daarom is het van het grootste belang dat ontwikkelteams dezelfde codeerrichtlijnen volgen. Om twee snelle voorbeelden te geven:
var name = 'Joe'; // reguliere if (naam === 'Jeff') alert ("Dat ben ik"); else alert ("Nee"); // ternair (naam === 'Jeff')? alert ("That's me"): alert ("Nee"); // Nee && Voor Short-hand-voorwaardes? var getTweets = true; // regular if (getTweets) alert ('getting now now'); // Logisch EN // Right-side wordt niet uitgevoerd, tenzij de linkerkant "true" is getTweets && alert ('Nu ophalen'); Veel ontwikkelaars fronsen het gebruik van het logische EN in dit geval erop aandringen dat het de leesbaarheid beperkt. Dit is zeker een geldig argument, maar zelfs populaire bibliotheken zoals jQuery maken veelvuldig gebruik van deze methode.
Om nogmaals te herhalen, de specifieke conventies die u kiest, zijn veel minder belangrijk dan ervoor te zorgen dat u consistent blijft met uw gebruik. Veel ontwikkelteams schrijven zelfs hun eigen conventie-richtlijnen voor nieuwe ontwikkelaars. Bedankt voor het lezen!
