Cinque o meno suggerimenti per scrivere un buon JavaScript? [chiuso]

JavaScript è ovviamente diventato piuttosto indispensabile; tuttavia, sono ancora nuovo, e ho trovato difficile combattere la sensazione che sembra un tale casino e non voglio affrontarlo in questo momento. Sono molto più a mio agio nella comprensione di altre lingue rispetto a JavaScript, perché non riesco a gestire questa paura. Ho la sensazione che, quando scrivo JavaScript, sto cercando di dipingere un ritratto dei cuccioli di Weimaraner.

Di solito mi aiuta a tenere a mente alcune delle direttive più importanti che posso chiedermi per ogni mossa che faccio. (A mio avviso, una manciata è cinque o meno.)

Puoi elencare cinque (o meno) domande specifiche su JavaScript che dovrei farmi per ogni mossa che faccio, quando sto codificando JavaScript? Cosa sarebbero?

Aggiornamento: per chiarire, non sto chiedendo cinque cose da tenere a mente durante l'apprendimento di JavaScript; Sto chiedendo cinque domande da farmi sempre andare avanti, che tutti dovrebbero sempre chiedere. Domande di alto livello come: "È probabile che lo ripeta da qualche altra parte?" o "questo nome di variabile / funzione è abbastanza specifico (o troppo specifico)" <== eccetto queste domande di esempio non sono peculiari di JavaScript. Sto cercando direttive specifiche per JavaScript.

Risponderò a questo in due parti. Uno è "Cinque o meno suggerimenti su come imparare a scrivere un buon JavaScript". L'altro è "Cinque o meno suggerimenti per scrivere un buon JavaScript".

Apprendimento:

1. Fare domande
2. Ascolta
3. Leggere
4. Fai cose

fare:

1. Evita i globi (modularizza)
2. Fai le cose difficili al di fuori dei loop (selezione DOM, dichiarazioni di funzioni, ecc.)
3. Scopri come funziona scope
4. Scopri quando e come utilizzare le chiusure
5. Scopri come funziona Object Oriented JS

MODIFICA (aggiunta di domande per conformarsi al PO):

A quale scopo mi riferisco?

Questo dovrebbe aiutare con i globuli trapelati, i gestori di eventi e quando utilizzare le chiusure.

Mi sto ripetendo?

L'astrazione e l'uso corretti delle tecniche OO sono importanti. Usali saggiamente.

Il mio codice si ripete da solo?

È straordinariamente facile ritrovarsi a inserire l'accesso DOM in un ciclo o a creare funzioni (anonime o di altro tipo) in un ciclo. Si noti che ciò può valere per il codice che utilizza setTimeouto setIntervalper i loop tradizionali.

Questo significa ciò che penso significhi?

I valori di verità e falsità in JS possono essere un po 'complicati, specialmente quando si usano confronti non rigorosi ( ==al contrario di ===). Anche la digitazione dinamica, la coercizione del tipo e se si fa riferimento a oggetti o valori letterali possono essere rilevanti.

Innanzitutto, sappi come funziona la tecnologia.

Devi saperlo perché hai le conoscenze su come funziona, perché ti imbatterai in problemi di rete o, come ho visto innumerevoli volte, le persone non riescono a capire cosa siano realmente il lato server e lato client. Una delle domande newb più comuni che vedo è "Come posso fare in modo che JS cambi una variabile nel mio codice ASP ?!"

• Capisci ethernet / wifi e TCP / IP per avere un'idea generale di cosa sta succedendo?
• Quanto HTTP conosci veramente?
• Hai effettivamente HTML? Certo, potresti sapere come funzionano i tag e annidare le cose, ma in realtà capisci la modalità doctype e le stranezze? Capisci che non dovresti mettere i tag di paragrafo attorno a un elemento dell'elenco?
• Inventa JavaScript (e spiega che può essere eseguito sul lato server). ecmascript, livescript, mocascript, jsscript, nodo ...
• Impara l'API di Windows, impara l'API DOM e impara l'API XHR. Se non conosci queste tre cose, non hai un codice di scrittura aziendale per il browser.

Comprendi che il tuo codice è più grande di te o della tua situazione specifica

• Certo, hai scritto qualcosa, ma tutti possono vederlo. È tutto "aperto". Certo, puoi offuscarlo, minimizzarlo, qualunque cosa ... alla fine della giornata, se voglio vedere il tuo codice, è banale per me sconfiggere qualsiasi metodo tu abbia messo in atto.
• È necessario comprendere le differenze di più browser. Scegli come target quelli più popolari o quelli del tuo mercato demografico. Ad esempio, ie6 non eseguirà il rendering degli elementi delle celle di tabella DOM se aggiungiChild anziché i metodi API DOM specificamente per le tabelle. Esistono altri esempi, è necessario impararli.
• Devi capire come scrivere il codice su tutti questi problemi nei browser, non nel tuo browser specifico. Imparerai rapidamente che le cose che funzionano bene in un browser sono lente in un altro. Dovrai capire come funzionano i browser e perché sono diversi.
• Per amore della barba di Odino, non scrivere codice che mi permetta di eseguire attacchi di cross-site scripting sul tuo codice. Se fai una chiamata Ajax a una cella e fai qualcosa di simile cell.innerHTML = "<script>alert("xss")</script>", e viene visualizzata una finestra di avviso, hai sbagliato.
• Stai alla larga da DynamicDrive, w3Schools e siti Web che danno cattivi consigli. Devi trovare comunità che diano buoni consigli. Qui su Stack Overflow abbiamo le chat room JavaScript e Node.JS e facciamo del nostro meglio per continuare a spingere i limiti del "meglio", dove siti come w3 mantengono i dati obsoleti e non si preoccupano mai di farlo. È necessario attenersi ai siti di specifiche ufficiali come W3C , Mozilla Developer Network (MDN). Richiedi una revisione tra pari del tuo codice. Quando ti senti come se stessi facendo qualcosa di doloroso con il tuo codice, quando stai facendo molto cut + paste + tweak con il tuo codice, dovresti immediatamente venire in una chat room e chiedere una guida per scrivere un codice migliore.
• Quando vieni a chiedere assistenza o vuoi condividere quella cosa davvero interessante che hai fatto ... per favore, per favore. Per favore, assicurati di averlo documentato, assicurati che i nomi delle tue variabili abbiano un senso, assicurati che non siano tutti allineati. Devi scrivere un codice pulito. Se hai un mucchio di immondizia, non solo hai fallito, nessuno che saprà aiutarti ti vorrà . Aiutaci ad aiutarti.
• Vuoi scrivere JavaScript, va bene, rispetto che non tutti supportano JavaScript. Due ragioni per questo: 1) Internet più veloce per tutti (piuttosto che "ajax tutte le cose" che porta a un'esperienza più lenta). 2) Il Web è più accessibile alle persone che utilizzano browser basati su console, alle persone che non usano script, ai telefoni cellulari. Quello che sto cercando di dire è che il tuo sito dovrebbe degradarsi con grazia se qualcuno non ha JavaScript e, per lo meno, utilizzare i <noscript>tag per avvisarli di ciò.
• A causa della natura prototipo di JavaScript, puoi apportare modifiche al modo in cui la lingua funziona davvero, il che è davvero dolce. Vedi, JavaScript si sta evolvendo, stiamo uscendo da "ECMA Script 3", che è la versione precedente di JS, e in "ECMA Script 5" (aka, es5). Grazie al prototipo, possiamo correggere il linguaggio es3 sul campo in modo che funzioni come es5. Ciò significa, ad esempio 6, che un browser di 10 anni ottiene la funzione di lingua che è stata pubblicata l'anno scorso. Usa gli spessori es5 dove puoi, sono davvero fantastici e devi guardarci dentro.
• Il mondo occidentale dei bambini bianchi di lingua inglese non è chi usa Internet. Codice di conseguenza. Ciò significa che è necessario comprendere l'internazionalizzazione e scrivere un codice che gestisca una domanda più elevata. 10 anni fa c'erano meno di 500 milioni di persone online, oggi sono circa 2 miliardi e in altri 10 anni? Probabilmente vicino a ogni persona sul pianeta avrà accesso a Internet, il che significa che devi supportare nomi che non si adattano alla regex di /[a-z ']/i, ma includono accenti hindi, arabo (questo è un problema esistente da parte di sviluppatori miopi), cinese , e altri. Comprendi i set di caratteri, Unicode e UTF-8.

Sei un programmatore, non un pastificio. Smetti di scrivere spaghetti.

• Dai un nome alle tue variabili in base a cose sensate.
• Documenta il tuo codice. Non mi interessa se stai usando JSDoc alimentato da rhino o hai un sacco di scarabocchi. Scrivi documentazione che aiuti la persona che utilizzerà il tuo codice. Scrivi documentazione per qualcuno che vuole migliorare o mantenere il tuo codice. Includi commenti utili. Commenti come "This fizzes the bizz"o quelli mezzo inglese mezzo francese non sono utili. Descrivi cosa fa una funzione. Descrivi sezioni complesse di codice.
• Scopri come limitare la ripetizione del codice. Cerca design modulare o modelli funzionali. Vedi cosa puoi astrarre. Non dovresti mai finire per tagliare + incollare + modificare grandi segmenti di codice per fare la stessa cosa.
• Devi comprendere l'API DOM. Il DOM e gli oggetti finestra forniscono molte cose fantastiche. Sembra un sacco di lavoro, ma è perché è un acronimo spaventoso. A molti ninja JavaScript piace scrivere codice come <a href="javascript:alert("foo")">. FFS NON LO FA. Attendi il caricamento del documento completo, separa il tuo codice JavaScript dal documento html. Queste sono le pratiche OOP di base 101, ma non allineare mai il tuo JS o CSS nel tuo documento HTML, mai. Scopri come farlo correttamente o trova qualcuno che sappia mostrarti come farlo. Ancora una volta, fai domande.
• il Javascript:foo("buz")è un psudeo-protocollo, non è pienamente supportato, e se non lo fai in linea javascript non sarebbe utilizzando in primo luogo. Ti prometto dal profondo del mio cuore che non c'è motivo per cui su questa terra o in qualsiasi parte dell'universo che DEVI inserire il tuo javascript all'interno di un elemento HTML. Mai. Quindi non farlo. Non aiuterò nemmeno più le persone che lo fanno più, è così male.

Scopri come scrivere il codice in modo che non si rompa continuamente.

• Le variabili globali sono uno dei maggiori problemi. Scopri come funziona la programmazione funzionale in JavaScript. Scopri cos'è il sollevamento. Scopri come evitare le variabili globali.
• Utilizzare strumenti di analisi del codice statico. Questi ti avvertiranno immediatamente di tutti i piccoli "spunti" che hai fatto durante la scrittura del codice. Hai dimenticato un punto e virgola da qualche parte? Oh, eccolo. Hai un globale da qualche parte? Oh, eccolo. Codice che potrebbe generare un sacco di errori misteriosi quando si tenta di eseguirlo? OH! Sono là! Non dovrai più andare in giro a guardare un mucchio di codice per ore, cercando di capire qualcosa che è solo un errore di sintassi. (Beh, quasi nessuno, potresti aver fatto qualcosa che non può catturare, ma è generalmente fantastico).
• Test unitario. Non c'è motivo di non esserlo. Ci sono tonnellate di strumenti di test unitari là fuori. Fondamentalmente, il test unitario è "Ecco la mia funzione" e "Voglio che emetta Y" "Ecco alcuni input di test" E il test è "Hanno funzionato tutti?" Esistono molti framework di test JS, come il popolare QUnit. Fai un tour attraverso il tuo motore di ricerca preferito e scopri cosa solletica la tua fantasia. Ma usali.
• Gestione del controllo del codice sorgente, noto anche come controllo della versione. Git è popolare e con buone ragioni. Così è SVN e pochi altri. Quello che vi serve per smettere di fare questo stesso istante è la modifica del codice di produzione. Devi smettere di rinominare i file. main_backup_20110911.js.bak.1Perdi roba, la tua directory diventa disordinata, non puoi facilmente "riavvolgere" un momento precedente. Non puoi vedere cosa sta succedendo, non puoi creare patch di codice. Quindi, inizia a imparare GIT, dovresti impiegarti un'ora e non tornerai mai indietro.
• Revisione tra pari. Non sei così bravo, nemmeno io. Sto meglio chiedendo feedback il più possibile. Ecco come dovresti farlo anche tu.

Scrivi JavaScript che le persone amano

• Scopri perché il tuo codice è lento. Utilizzare jspref e creare test.
• Smetti di associare eventi a un elemento DOM, è lento e crea seri problemi di bolle che sprecheranno molto del tuo tempo. Ricerca "delegazione di eventi" in JavaScript.
• FERMARE di usare innerHTML per modificare il DOM. Questo risale all'apprendimento dell'HTML e all'apprendimento del DOM. HTML sono i dati inviati dal server che il motore di rendering del browser utilizza per creare un gruppo di oggetti di programmazione che finiscono per essere un oggetto documento. Quando usi innerHTML stai chiedendo al tuo browser di eseguire nuovamente il rendering del tutto. Per fortuna, come più di 10 anni fa, abbiamo creato l'API DOM e ti consente di "aggiungere figlio" o "creare nodo di testo" senza dover aggiornare il tutto. innHTML è una vergogna inventata da Microsoft: se lo usi, perdi anche tutti i privilegi per lamentarti del fatto che IE6 sia terribile perché stai aiutando il suo cestino della spazzatura per sempre. Impara il DOM.
• Deve funzionare ovunque possibile. Se qualcosa non è supportato, deve degradarsi con garbo, quindi l'esperienza non fa schifo, non puoi semplicemente schiaffeggiare i tuoi utenti e schiantarti.
• Il copyright e la licenza sono importanti. Non fregare il duro lavoro degli altri. Se qualcuno dice "non per la rivendita", non puoi venderlo. Non fare il cretino, o odieremo il tuo codice per fregare le persone che lavorano duramente.
• JS è prototipi, non classi. Smettila. Se non capisci come funziona il prototipo, devi farlo. Google esso. JavaScript non è basato su classi, smetti di provare a creare classi, molto raramente funziona bene. Le persone cercano di scrivere codice classico in un linguaggio prototipo e di usarlo come caso per "perché il linguaggio fa schifo", potrei fare lo stesso caso per Ruby che non è in grado di supportare il prototipo. Scopri qualcosa di nuovo e smetti di sbagliare.

Concentrati sulle basi, sempre.

• Ti sbagli, ed è fantastico, perché sai qualcosa adesso. Niente è peggio di qualcuno che non ammetterà di sbagliarsi e continuerà a sbattere fuori dal codice cattivo come se fossero dei ninja supereroi rock star rinnegati. Sono solo pazzi. Ammetti che puoi sbagliare, ammetti che potresti sbagliare, chiedi aiuto.
• Non hai sempre bisogno di jQuery. jQuery crea molto codice lento e aiuta le persone che non conoscono JS a scrivere JS. Questo è un ulteriore problema poiché JS non richiede di conoscere JS per scrivere JS. Vai a capire. Una volta comprese alcune delle cose che ho menzionato sopra come l'apprendimento di eventi, l'apprendimento del DOM, l'apprendimento di innerHTML, capirai perché jQuery può essere dannoso per il tuo codice. Può essere utilizzato correttamente in molti luoghi, ma spesso è possibile utilizzare una libreria più piccola o anche boccheggiare il JavaScript standard fornito con il browser per realizzare qualcosa. Non hai bisogno di jQuery per fare nulla, è più facile scrivere del codice che è interessante se stai imparando ma devi iniziare a fare meglio e imparare di più - quando ne saprai di più, scoprirai come scrivere comunque un codice migliore in jQuery.Scopri alcune altre librerie JavaScript e smetti di essere così affiatato.
• Non è necessario tagliare + incollare + modificare, creare il codice DRY. Ne ho già parlato prima, ma è importante anche qui. Non puoi scrivere il codice di qualità se la tua base di codice è una disgrazia.
• Non abusare di array / differenze di oggetti, impara come eseguire il loop. Scopri perché usi a for (;;)e perché usi un for( in )loop. Quando utilizzare un ciclo while. Smetti di annidare gli IF quando puoi semplicemente usare una custodia. Gli oggetti non mantengono l'ordine, quindi non li usano come un array; vecchia Opera / FF, vecchia MISE, a volte Flash non rispetterà l'ordine dei tuoi oggetti. Usa un array se vuoi mantenere un ordine di cose, usa un oggetto se vuoi un oggetto (qualcosa che non ha un ordine di elementi).
• Come le strutture decisionali possono essere utilizzate a tuo vantaggio, non aggiungendo complessità al tuo codice. Smetti di annidare gli IF, scopri come funzionano gli operatori logici booleani. Scopri come funziona la custodia.
• RTFM. Il posto migliore per conoscere il codice migliore è leggere le specifiche effettive. Leggi le specifiche RFC su quella parte di codice che stai tentando di utilizzare. Leggi il documento ECMAScript. Leggi le specifiche DOM W3C. Leggi le specifiche W3C XHTML / HTML / HTML5. Leggi le specifiche, sono buone.

Concentrati sul gioco lungo, non su un lampo rapido e muori.

• Dovresti aiutare la community, dovresti scrivere del codice che rimarrà a lungo in circolazione. Abbi una certa passione per il tuo codice e la tua community. Se hai lasciato cattive conoscenze da qualche parte, torna indietro e correggilo. Le cattive informazioni sono davvero difficili da eliminare e restano per sempre. Fai la tua parte. Non aiutare w3schools a peggiorare il Web.
• Non saltare dal nulla e dire "Ehi, ho una grande idea su come usare which" rilascia un mucchio di codice che nessuno può usare e scompare. Non hai contribuito. Non usare variabili come ae chezburger.
• Impara a individuare il cattivo codice e il buon codice, trovalo nel tuo codice, trasforma il tuo cattivo codice in un buon codice.
• Crea qualcosa, impara qualcosa, insegna qualcosa.
• Allarga i tuoi orizzonti. Non puoi semplicemente scrivere JavaScript per sempre: prendi un anno sabbatico in qualcos'altro che ti interessa, torna indietro, condividi ciò che hai imparato e vedi se riesci a trovare un posto nella comunità. Prova a mostrare all'altro mondo quale valore ha anche JavaScript mentre sei là fuori.
• Ti sbagli ancora, anche quando sai tutto. Usa una prova per essere corretta, non il tuo stato / autorità. Non puoi mai avere ragione, ma la tua prova è sempre corretta. Non entrare in partite di pipì, tanto difficile quanto a volte evitare. O ci sono prove o non ci sono. Le fiamme non aiutano nessuno.

Per chiunque sia interessato, in realtà ho preso la maggior parte di questo da note personali in un tutorial che non ho mai scritto.

1. Leggi il Javascript di Douglas Crockford : le parti buone . Questo è piuttosto un consiglio, ma onestamente, è il miglior consiglio che io abbia mai sentito per aver scritto un buon javascript.

2. Leggi anche gli articoli di Douglas Crockford su Javascript .

alert('This illustrates how JavaScript has first-class functions');
alert('It also illustrates how to use closures.  Try running this code in your browser.');

var funky = function(s) {
    alert("We're getting funky with " + s);
};

var makeFunkyObject = function(funkyFunction) {
    var numberOfTimesAlerted = 0;
    var fn = { };
    fn.alertFunky = function(s) {
        funkyFunction(s);
        numberOfTimesAlerted++;
    }
    fn.getNumberOfTimesAlerted = function() {
        return numberOfTimesAlerted;
    }
    return fn;
}

var funkyObject = makeFunkyObject(funky);

funkyObject.alertFunky('Alice'); // alerts We're getting funky with Alice
funkyObject.alertFunky('Bob'); // alerts We're getting funky with Bob
alert(funkyObject.getNumberOfTimesAlerted()); // alerts 2

alert('Also, be sure to distinguish between learning about JavaScript and learning about the DOM');
alert('The former is awesome; the latter, not so awesome.');

Ecco alcune domande che dovrebbero farti andare su JavaScript.

1. Come funziona JSON ea cosa serve?

2. Perché gli oggetti funzioni in Javascript?

3. Perché non dovrei usare eval?

4. Come posso creare eventi in javascript?

5. Come faccio a rilevare le funzionalità in JavaScript?

Praticamente copre la maggior parte delle cose che devi fare in Javascript.

1. Usa sempre il punto e virgola. I punti e virgola impliciti (in JS) sono un'idea orribile, specialmente con alcune interessanti sintassi che circolano nell'uso comune. Sono inoltre generalmente richiesti da qualsiasi minificatore JS.
2. Evita eval () . Ciò causa tutti i tipi di problemi ed è un modo molto rapido per rallentare l'applicazione. La maggior parte degli usi sono in realtà abusi. Ogni volta che pensi di dover utilizzare eval(), ricontrolla e triplica per un altro modo; c'è quasi sempre un modo più semplice e pulito a meno che tu non stia effettivamente cercando di eseguire un'intera stringa del valore di JavaScript.
3. (function() {/* stuff */})()è un buon modo per racchiudere un insieme di codice e creare un ambito locale per esso. L'uso degli oggetti è un altro modo, spesso migliore; gli oggetti sono più analoghi agli spazi dei nomi in altre lingue se usati in questo modo. Stai attento this. A differenza della maggior parte delle altre lingue, thisnon sempre fa riferimento a ciò che potresti pensare intuitivamente. Ricorda inoltre che, se non diversamente specificato, tutte le variabili JS, le funzioni e gli altri oggetti sono tutti globali, anche su più .jsfile.
4. Trova e impara / usa una buona libreria JS. jQuery è uno dei più popolari. Ciò comporterà molto per te, tra cui cose come il rilevamento di funzionalità e l'astrazione della manipolazione del DOM e i molteplici modi in cui diverse cose sono state implementate in diversi browser.
5. Usa sempre il punto e virgola. Sul serio. Ottieni un IDE che ti avverte quando li dimentichi. Non voglio sembrare ranty, ma ci sono state alcune volte in cui sono stati introdotti bug solo per la mancanza di un punto e virgola e il browser non ti avviserà di questi.

Credo che le classi siano uno strumento abbastanza potente per strutturare il codice. Ci sono molte regole di linguaggio agnostico su come progettare sistemi basati su classi e alcuni principi OO sono effettivamente più ovviamente implementati quando si usano le classi.
Pertanto ti suggerisco di dare un'occhiata a CoffeeScript .

Da lì, ti suggerisco di provare a raccogliere informazioni su come implementare SOLID , DRY , GRASP , KISS e YAGNI e, soprattutto, come affrontare situazioni in cui sembrano essere in conflitto (non fanno mai, solo la tua comprensione di loro o il problema attuale lo fa). È abbastanza facile da trovare, anche su stackexchange.

Si noti che questi principi si applicano anche allo sviluppo JavaScript "non elaborato". Tuttavia, molti dei contenuti che troverai su di essi li illustreranno usando linguaggi basati su classi e potrebbe quindi essere utile programmare in una lingua, dove non ci sono troppe spese generali per capirli.
Personalmente, penso che JavaScript sia un linguaggio estremamente potente, ma in realtà dovrai prima capire profondamente altre lingue, per apprezzare davvero questo fatto.

Sto assumendo che tu stia utilizzando JavaScript per lo sviluppo dell'interfaccia utente sul lato client in un'applicazione web.

1) Questo dovrebbe essere lato client o dovrebbe essere lato server? So che sono andato a scrivere grossi pezzi di codice che meritavano davvero di essere sul lato server e viceversa. Molte volte andrò a fare una chiamata AJAX per qualcosa che finisce semplicemente meglio inserito nel codice del server per essere incluso sulla strada. Soprattutto cose di natura statica ma che cambiano abbastanza regolarmente (ad esempio un elenco di categorie).

2) Esiste già un plug-in che lo fa già? Uso molto JQuery e la risposta è quasi sempre SÌ! Prenderò spesso il codice plugin che qualcuno ha scritto e lo adatterò alle mie esigenze (di solito aggiungendo classi extra alle cose, ecc.) Ma raramente devo mai ricominciare da zero.

3) Javascript è il posto giusto per questo? Occasionalmente mi sorprendo ad aggiungere un sacco di stile dinamico a qualcosa tramite Javascript quando ha molto più senso usare CSS intelligenti.

4) Dovrei usare uno strumento diverso? Questo è qualcosa con cui ho avuto a che fare ultimamente. Ci sono alcune alternative javascript come lo script del caffè che sono gestite bene nel mio stack (Rails 3.1) e ho considerato se spostare gran parte del mio codice lì.

5) Questo codice Javascript è un buon codice? Javascript è un codice come qualsiasi altro codice. Questo codice è buono come il resto del mio codice? In caso contrario, perché no? È buttato via? Sono pigro?