Share
Soprattutto quando si inizia per la prima volta con vari linguaggi di sviluppo Web, può risultare difficile imparare tutte le varie convenzioni di denominazione dalla lingua alla lingua. Questo può essere ancora più confuso quando gli sviluppatori non sono d'accordo su ciò che è considerato la migliore pratica. Per facilitare la transizione per i principianti, questa lista descriverà alcune delle convenzioni più comuni.
Quando si incontra una variabile o un metodo che è preceduto da un _, non c'è magia voodoo che viene eseguita dietro le quinte. È semplicemente una convenzione di denominazione che ricorda allo sviluppatore che la variabile / proprietà / metodo è o privato o protetta, e non è possibile accedervi dall'esterno della classe.
// Questa variabile non è disponibile al di fuori della classe $ _someVariable privata; class MyClass // Questo metodo è disponibile solo all'interno di questa classe, o // tutti gli altri che ne ereditano. funzione protetta __behindTheScenesMethod ()
Nota che, nel codice sopra, il carattere di sottolineatura non è quello che fa la variabile o il metodo privato; il privata / protetta la parola chiave lo fa. Il trattino basso è solo un promemoria per sei mesi lungo la strada!
var Person = (function () var _trueAge = 50, _trueWeight = 140; return age: _trueAge - 15, weight: _trueWeight - 30;) (); Personaggio; // 35 Person.weight; // 110 Person._trueAge; // non definito (perché è privato, yo)
Facendo Persona uguale a, non a funzione, ma il ritorno oggetto, possiamo creare variabili private. Ancora una volta, il prefisso sottolineatura ci ricorda questo.
UN costante è una variabile con un valore statico, che non cambierà. Ad esempio, se il tuo progetto richiede la necessità di moltiplicare un valore con la tassa statale, potresti assegnare questa tariffa, $ .0825 a a costante. Tuttavia, non tutte le lingue hanno questi tipi di variabile incorporati. Pertanto, è buona norma usare tutte le lettere maiuscole per ricordare a te stesso che stai lavorando con un costante. Questa è una convenzione comune nel mondo JavaScript e viene utilizzata come oggetto nativo Math.PI.
var TAXRATE = .0825;
Accentsconagua
define ('TAXRATE', .0825); A un certo punto, sicuramente hai trovato una variabile che è stata preceduta da una singola lettera, ad esempio "S" o "io".
$ sName = 'Capitan Jack Sparrow';
Questo è indicato come Notazione ungherese, ed è caduto in disgrazia negli ultimi anni, sebbene sia ancora una convenzione utilizzata da molte aziende.
La notazione ungherese è una convenzione di denominazione che ricorda allo sviluppatore
generedi variabile con cui sta lavorando:STring,ionteger, eccetera.
Soprattutto nel mondo JavaScript, questa pratica è disapprovata, perché è un linguaggio vagamente dattiloscritto. Un linguaggio a caratteri generici è uno che non richiede di dichiarare il tipo di dati di una variabile. Perché è così significativo? Cosa succede se, utilizzando la convenzione di notazione di cui sopra, abbiamo dichiarato una stringa con il "S" prefisso, ma in seguito ha cambiato la variabile in un numero intero? A quel punto, questa forma di notazione funzionerebbe di fatto contro di noi, non per noi.
var sName = "Tenente comandante Geordi La Forge"; typeof (sName); // string ... sName = undefined; typeof (sName) // undefined
Utenti di jQuery: prima di calpestare il piedistallo e lodare te stesso per non usare questa forma di notazione, chiediti se hai il prefisso delle variabili - racchiuse nell'oggetto jQuery - con un simbolo del dollaro? Se è così, questa è una forma di notazione ungherese. È un simbolo preceduto da un nome variabile che ha il solo scopo di informarti sul tipo o le qualità della variabile.
// Il simbolo del dollaro mi ricorda che questa variabile // ha accesso ai vari metodi di jQuery. var $ container = $ ('# container'); Dipende solo da te. Anche molti membri del team jQuery usano il metodo del prefisso dollaro. In definitiva, se funziona per te, questo è tutto ciò che conta. Personalmente, a partire da circa un anno fa, non uso più il prefisso del simbolo del dollaro, ma solo perché ho capito che non era necessario per me. Deciditi su questo.
Che dire di quei nomi "variabili", che capitalizzano la prima lettera del nome?
$ response = $ SomeClass-> doSomething ();
Nel codice sopra, $ SomeClass è maiuscola perché è a classe e non a variabile nome. Ancora una volta, questa è una convenzione di denominazione utilizzata dalla maggior parte degli sviluppatori. Quando si ritorna al codice un anno dopo, è un po 'piccolo lampadina questo li informa che stanno lavorando con una classe, che ha oggetti e metodi disponibili.
// Nota la capitale M nel nome della classe. class $ MyClass function __construct ()
In JavaScript, non abbiamo davvero classees; ma noi abbiamo costruttore funzioni.
var Jeff = new Person ();
Il motivo per cui capitalizziamo il nome del costruttore (Persona) è perché può essere facile dimenticare a volte il nuovo parola chiave. In queste circostanze, JavaScript non invierà alcun avvertimento e potrebbe essere un incubo rintracciare il problema. La maiuscola è un avviso utile per lo sviluppatore, durante il debug. Douglas Crockford è un grande sostenitore di questa convenzione.
In alternativa, se vuoi proteggere contro la dimenticanza del tuo io futuro, puoi prima assicurarti che il costruttore sia, in effetti, corretto, prima di procedere.
function Person (name) // Se la nuova parola chiave è assente, il costruttore sarà la finestra. // In questo caso, compensa e restituisci una nuova istanza se (this.constructor! == Person) return new Person (name); this.name = nome; // Intenzionalmente dimenticato la parola chiave "new" var Joey = Person ('Joey'); Joey.name; // Joey Perché alcune variabili usano un pattern CamelCase, mentre altri usano un trattino basso per separare le parole? Qual è il metodo corretto? La risposta è che non c'è corretta utilizzo. Dipende interamente dalla lingua e dalle convenzioni di codifica della tua azienda. Entrambi sono perfettamente accettabili.
// camelCase var preacherOfSockChanging = 'Lieutenant Dan'; // under_score var preacher_of_sock_changing = 'Tenente Dan';
Tuttavia, con tutto ciò che è stato detto, è una buona pratica - quando hai la possibilità - di seguire le convenzioni comuni della lingua che stai utilizzando. Ad esempio, la grande maggioranza degli sviluppatori JavaScript utilizza la sintassi camelCase, mentre altri linguaggi, come PHP, tendono a preferire l'uso del trattino basso. Anche se, di nuovo, questo non è scolpito nella pietra. Il framework Zend sostiene il CamelCasing come una buona pratica.
Più importante di quello che usi è assicurarsi di attenervisi!
Soprattutto quando si lavora in un team, è essenziale adottare la struttura di directory appropriata come i propri colleghi sviluppatori. Ma, per lo meno, certamente non lasciare tutti i fogli di stile e gli script nella radice del progetto, senza alcuna organizzazione. Molti sviluppatori preferiscono posizionare tutte le loro immagini, script e fogli di stile all'interno di un genitore Risorse elenco.
/ Project Root / Assets / js / min script_min.js script.js / css / min style_min.css style.css / img img1.jpg index.html otherFile.html
Inoltre, nota la convenzione di creare anche a min cartella, che contiene le versioni minificate aggiunte dinamicamente degli script e dei fogli di stile.
Quando si crea mark-up, si spera, è ampiamente compreso che il ids e classeLe tue scelte dovrebbero descrivere il tipo di contenuto e non gli aspetti di presentazione. Come esempio:
Justin Bieber è la mia sezione homeboy.
Justin Bieber è la mia sezione homeboy.
Justin Bieber è la mia sezione homeboy.
Come mai? Che cosa succede se, sei mesi lungo la strada, decidi di posizionare la tua sezione di fan di Justin Bieber in middle-destra-e-poi-un-po-inferiore sezione? A quel punto, il tuo id avrà poco senso.
Nel momento in cui entriamo in un mondo HTML5, dovresti trovarti ad usare molti meno identificatori nei tuoi elementi.
ids sono meno flessibili e sono molte volte inutili.
Intestaziones e footerS Sai cosa puzza? Quando si lavora su un sito Web centrato che richiede più sfondi che si estendono per l'intera larghezza della finestra (in genere per il intestazione e footer), in genere devi avvolgere il contenuto in modo che l'elemento esterno si estenda, mentre l'elemento interno può rimanere centrato.
Poiché questo è un problema comune, è importante adottare una convenzione comune per creare il margine necessario.
La decisione difficile qui è che, supponendo che tu stia lavorando con i nuovi elementi HTML5, devi decidere se posizionare il footer elemento all'interno o all'esterno. È ancora in discussione, tuttavia, tendo a pensare che sia più semantico collocare il reale footer elemento all'interno.
divs dovrebbe essere usato solo quando:
Decidi ora se consentire o meno l'uso di scorciatoie nel tuo codice. Scrivere un codice preciso / pulito è sempre una battaglia di leggibilità e dimensioni. Questo è il motivo per cui è fondamentale che i team di sviluppo seguano le stesse linee guida di codifica. Per fornire due esempi rapidi:
var name = 'Joe'; // regular if (name === 'Jeff') alert ("Sono io"); else alert ("Nope"); // ternary (name === 'Jeff')? alert ("That's me"): alert ("Nope"); // No && Per i condizionali a mano corta? var getTweets = true; // regular if (getTweets) alert ('ottenerle ora'); // Logical AND // Il lato destro non verrà eseguito, a meno che il lato sinistro sia "vero" getTweets && alert ("Ottenere ora"); Molti sviluppatori disapprovano l'uso della logica E in questo caso, insistendo sul fatto che limita la leggibilità. Questo è certamente un argomento valido, tuttavia, anche le librerie popolari come jQuery sfruttano pesantemente questo metodo.
Per ribadire, le convenzioni specifiche che scegli sono molto meno importanti di garantire che tu rimanga coerente con il tuo utilizzo. In effetti, molti team di sviluppo scrivono le proprie linee guida sulla convenzione per i nuovi dipendenti. Grazie per aver letto!
