Merge branch 'master' into master

Author: longo-andrea

1-js/01-getting-started/2-manuals-specifications/article.md

@@ -24,9 +24,12 @@ Inoltre, se state sviluppando in ambiente browser, ci sono ulteriori specifiche
     Tuttavia, spesso è meglio fare una ricerca su internet. E' sufficiente cercare "MDN", seguito dal termine da ricercare, e.g. <https://google.com/search?q=MDN+parseInt> per ricercare la funzione `parseInt`, oppure frasi come "RegExp MSDN" o "RegExp MSDN jscript".
 
 
+    Può essere consultato al link <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference>.
+
 - **MSDN** – Manuale Microsoft con molte informazioni, tra cui su JavaScript (a cui viene fatto riferimento con il termine JScript). Se si ha bisogno di ottenere qualche informazione specifica per Internet Explorer, meglio consultare la guida: <http://msdn.microsoft.com/>.
 
 
+
 ## Tabelle di compatibilità
 
 JavaScript è un linguaggio che muta costantemente, con nuove funzionalità che vengono aggiunte regolarmente.

1-js/03-code-quality/02-coding-style/article.md

@@ -2,7 +2,7 @@
 
 Il codice dovrebbe essere il più pulito e leggibile possibile.
 
-Questa è l'arte della programmazione -- programmare funzionalità complesse che siano allo stesso tempo correte e leggibili. Un corretto stile di programmazione aiuta molto in questo senso.
+La programmazione è come un arte -- dobbiamo essere in grado di programmare funzionalità complesse che siano allo stesso tempo correte e leggibili. Un corretto stile di programmazione aiuta molto in questo senso.
 
 ## Sintassi
 
@@ -42,7 +42,7 @@ Niente di quello che stiamo dicendo è scolpito sulla pietra. Sono solo delle pr
 
 ### Parentesi graffe
 
-In molti progetti JavaScript le parentesi graffe sono scritte con lo stile "Egiziano" con la parentesi aperta nella stessa linea della keyword -- non in una nuova linea. Dovrebbe comunque esserci spazio prima della parentesi aperta, come in questo esempio:
+In molti progetti JavaScript le parentesi graffe sono scritte seguendo lo stile "Egiziano" con la parentesi aperta nella stessa linea della keyword -- non in una nuova linea. Dovrebbe comunque esserci spazio prima della parentesi aperta, come in questo esempio:
 
 ```js
 if (condition) {
@@ -56,35 +56,53 @@ Un caso limite è un costrutto con una singola linea. Dovremmo comunque usare le
 
 Qui ci sono un paio di varianti, cosi potete giudicare voi stessi:
 
-1. 😠 Beginners sometimes do that. Bad! Curly braces are not needed:
+1. 😠 I principianti spesso fanno questo. Sbagliato! Le parentesi graffe nono sono richieste:
     ```js
     if (n < 0) *!*{*/!*alert(`Power ${n} is not supported`);*!*}*/!*
     ```
-2. 😠 Split to a separate line without braces. Never do that, easy to make an error when adding new lines:
+2. 😠 Inserire l'istruzione su nuova riga senza parentesi. Non dovreste mai farlo, poiché rende molto semplice commettere errori nel caso si volesse aggiungere un'altra istruzione:
     ```js
     if (n < 0)
       alert(`Power ${n} is not supported`);
     ```
-3. 😏 One line without braces - acceptable, if it's short:
+3. 😏 In una singola riga senza parantesi -- accettabile, se l'istruzione è semplice:
     ```js
     if (n < 0) alert(`Power ${n} is not supported`);
     ```
-4. 😃 The best variant:
+4. 😃 La variante migliore:
     ```js
     if (n < 0) {
       alert(`Power ${n} is not supported`);
     }
     ```
 
-For a very brief code, one line is allowed, e.g. `if (cond) return null`. But a code block (the last variant) is usually more readable.
-
-In sintesi:
-- Per codici molto brevi, una sola riga è accettabile. Ad esempio:  `if (cond) return null`.
-- Ma una singola riga per ogni istruzione è generalmente più facile da leggere.
+Per istruzioni molto brevi, è consentito scrivere su una sola riga, ad esempio `if (cond) return null`. Ma un blocco di codice risulta essere molto più leggibile.
 
 ### Lunghezza della riga
 
-Nessuno ama leggere lunghe righe orizzontali di codice. Una buona norma è dividere le righe più lunghe in qualcosa di più breve.
+Nessuno ama leggere lunghe righe orizzontali di codice. Una buona norma è quella di dividere le righe più lunghe in righe più brevi.
+
+Ad esempio:
+```js
+// i backtick consentono di dividere la stinga in più righe
+let str = `
+  ECMA International's TC39 is a group of JavaScript developers,
+  implementers, academics, and more, collaborating with the community
+  to maintain and evolve the definition of JavaScript.
+`;
+```
+
+Invece, per le istruzioni `if`:
+
+```js
+if (
+  id === 123 &&
+  moonPhase === 'Waning Gibbous' &&
+  zodiacSign === 'Libra'
+) {
+  letTheSorceryBegin();
+}
+```
 
 La lunghezza massima dovrebbe essere accordata a livello di team. Solitamente tra gli 80-120 caratteri.
 
@@ -98,7 +116,7 @@ Ci sono due tipi di indentazione:
 
     Un vantaggio degli spazi contro i tabs è che gli spazi permettono configurazioni più flessibili.
 
-    Ad esempio, possiamo allineare gli argomenti con l'apertura della parentesi, come qui:
+    Ad esempio, possiamo allineare gli argomenti con l'apertura della parentesi, come nell'esempio:
 
     ```js no-beautify
     show(parameters,
@@ -131,15 +149,15 @@ Ci sono due tipi di indentazione:
 
 ### Punto e virgola
 
-Un punto e virgola dovrebbe essere presente alla fine di ogni istruzione, anche se potrebbe essere evitata.
+Il punto e virgola dovrebbe essere presente alla fine di ogni istruzione, anche se non è obbligatorio.
 
-Esistono linguaggi in cui il punto e virgola sono realmente opzionali e possono essere evitati. In JavaScript, esistono casi in cui un "a capo" non viene interpretato come un punto e virgola, lasciando quindi il codice vulnerabile agli errori.
+Esistono linguaggi in cui il punto e virgola è realmente opzionale e può essere omesso. In JavaScript, esistono casi in cui un "a capo" non viene interpretato come un punto e virgola, lasciando quindi il codice vulnerabile agli errori.
 
-Quando diventerete più maturi come programmatori, potreste scegliere lo stile senza punto e virgola [StandardJS](https://standardjs.com/). Fino a quel momento la miglio scelta è di inserirla alla fine di ogni istruzione per evitare errori.
+Quando diventerete più maturi come programmatori, potreste scegliere lo stile senza punto e virgola [StandardJS](https://standardjs.com/). Fino a quel momento la scelta migliore è quella di inserirlo alla fine di ogni istruzione per evitare errori.
 
 ### Livelli di annidamento
 
-Nel codice vanno evitati elevati liveeli di annidamento.
+Nel codice vanno evitati elevati livelli di annidamento.
 
 Qualche volta torna utile la direttiva ["continue"](info:while-for#continue) per evitare annidamenti extra.
 
@@ -253,17 +271,17 @@ Se state scrivendo molte funzioni "ausiliarie", ci sono tre modi per organizzarl
     ```
 3. Mix: una funzione viene dichiarata nel punto in cui viene utilizzata la prima volta.
 
-Nella maggioranza dei casi si preferisce la seconda opzione.
+Nella maggior parte dei casi si preferisce la seconda opzione.
 
 Questo perché quando leggiamo il codice vogliamo prima di tutto sapere *cosa fa*. Mettendo prima il codice possiamo fornire queste informazioni. Successivamente, potrebbe non essere necessario leggere le funzioni, soprattutto se i loro nomi sono autodescrittivi.
 
-## Guida di stile
+## Style guide
 
-Una guida di stile contiene  regole generali riguardo a "come scrivere" il codice, ad esempio quali apici utilizzare, di quanti spazi indentare, quando andare a capo, etc. Molti altri dettagli.
+Una style guide contiene regole generali riguardo a "come scrivere" il codice, ad esempio quali apici utilizzare, di quanti spazi indentare, quando andare a capo, e molti altri dettagli.
 
-Quando tutti i membri del team utilizzano lo stesso stile tende ad essere uniforme.
+Quando tutti i membri del team utilizzano la stessa guida, il codice tende ad essere più uniforme.
 
-Certamente, un team può utilizzare il proprio stile guida. Molte volte non serve. Ci sono molte opzioni tra cui scegliere, quindi scegliere tra una di queste generalmente è la scelta migliore.
+Certamente un team può utilizzare la propria style guide, ma spesso non è necessario definirne una propria. Ce ne sono molte già pronte, scegliere una tra queste è generalmente la scelta migliore.
 
 Alcune delle scelte più popolari:
 
@@ -275,7 +293,7 @@ Alcune delle scelte più popolari:
 
 Se sei un nuovo sviluppatore, inizia con i consigli di questo capitolo. Quando avrai appreso bene lo stile potrai cercare quello che più ti appartiene.
 
-## Pulitori automatizzati
+## Linter
 
 I linters sono strumenti che controllano automaticamente lo stile del codice e vi danno consigli su come sistemarlo.
 
@@ -287,16 +305,16 @@ Alcuni fra i linter più conosciuti:
 - [JSHint](http://www.jshint.com/) -- molte più opzioni di JSLint.
 - [ESLint](http://eslint.org/) -- il più recente.
 
-Tutti quelli elencati svolgono molto bene il lavoro. L'autore utilizza [ESLint](http://eslint.org/).
+Tutti quelli elencati svolgono molto bene il lavoro. L'autore della guida utilizza [ESLint](http://eslint.org/).
 
-Molti linter sono integrati negli editor più popolari: è sufficiente attivare il plugin e configurare lo stile.
+Molti linter sono integrati negli editor più popolari: è sufficiente attivare il plugin e configurare lo stile desiderato.
 
-Ad esempio, per ESLint dovreste seguire quanto segue:
+Ad esempio, per poter utilizzare ESLint è sufficiente:
 
-1. Installare [Node.js](https://nodejs.org/).
-2. Installare ESLint con il comando `npm install -g eslint` (npm è package installer di JavaScript).
-3. Create un file di configurazione e rinominatelo `.eslintrc` nella root del vostro progetto JavaScript (la cartella che contiene tutti i file).
-4. Installa/abilita il plugin per il tuo editor per integrare ESLint. La maggior parte degli editor ne ha uno.
+1. Installa [Node.js](https://nodejs.org/).
+2. Installa ESLint con il comando `npm install -g eslint` (npm è un package manager di JavaScript).
+3. Crea un file di configurazione e chiamalo `.eslintrc` nella root del tuo progetto JavaScript (la cartella che contiene tutti i file).
+4. Installa/abilita il plugin per il tuo editor per integrare ESLint. La maggior parte degli editor ne possiede uno.
 
 Qui un esempio di di un file `.eslintrc`:
 
@@ -317,14 +335,14 @@ Qui un esempio di di un file `.eslintrc`:
 
 La direttiva `"extends"` indica che la configurazione è basata sulla lista dei setting "eslint:recommended". Dopodiché potremo specificare il nostro stile personale.
 
-E' anche possible scaricare un set di regole dal web ed estenderle a nostro piacimento. Vedi <http://eslint.org/docs/user-guide/getting-started> per maggiori dettagli riguardo l'installazione.
+E' anche possibile scaricare un set di regole dal web ed estenderle a nostro piacimento. Vedi <http://eslint.org/docs/user-guide/getting-started> per maggiori dettagli riguardo l'installazione.
 
 Molti IDE hanno dei linter integrati, che sono comodi ma non sono editabili come ESLint.
 
 ## Riepilogo
 
-Tutte le regole sintattiche descritte in questo capitolo (e nei riferimenti dei vari stili di programmazione) aiutano ad incrementare la leggibilità del codice, ma sono tutti contestabili.
+Tutte le regole sintattiche descritte in questo capitolo (e nei riferimenti delle style guides) aiutano ad incrementare la leggibilità del codice, ma sono tutte contestabili.
 
-Quando stiamo pensando a come scrivere codice "migliore", la domanda dovrebbe essere "Cosa rende il codice più leggibile e facile da capire?" e "Cosa può aiutarmi ad evitare gli errori?". Queste sono le principali cose da tenere a mente quando stiamo cercando di scegliere uno stile guida.
+Quando stiamo pensando a come scrivere codice "migliore", la domanda dovrebbe essere "Cosa rende il codice più leggibile e facile da capire?" e "Cosa può aiutarmi ad evitare gli errori?". Queste sono le principali cose da tenere a mente quando stiamo cercando di scegliere una style guide.
 
-Leggere fra gli stili più popolari vi consentirà di tenervi aggiornati con le ultime idee riguardo gli stili di programmazione e le best practices.
+Conoscere gli stili più popolari vi consentirà di tenervi aggiornati con le ultime idee riguardo gli stili di programmazione e le best practices.

1-js/03-code-quality/02-coding-style/code-style.svg

@@ -1,6 +1,6 @@
 # Commenti
 
-Come abbiamo già appreso dal capitolo <info:structure>, i commenti possono essere di una singola-riga: ed iniziano con `//` oppure multilinea: `/* ... */`.
+Come abbiamo già appreso dal capitolo <info:structure>, i commenti possono essere di una singola riga: ed iniziano con `//` oppure multilinea: `/* ... */`.
 
 Normalmente li utilizziamo per descrivere come e perché funziona il codice.
 
@@ -20,11 +20,11 @@ code;
 
 Nel buon codice la quantità di commenti "esplicativi" dovrebbe essere minima. In realtà il codice dovrebbe essere facile da comprendere anche senza.
 
-C'è una bellissima regola a riguardo: "Se il codice è cosi poco chiaro da richiedere un commento, probabilmente dovrebbe essere riscritto".
+C'è una bellissima citazione a riguardo: "Se il codice è cosi poco chiaro da richiedere un commento, probabilmente dovrebbe essere riscritto".
 
 ### Ricetta: raccogliere in una funzione
 
-Qualche volta può essere un beneficio rimpiazzare un pezzo di codice in una funzione, come in questo esempio:
+Qualche volta può essere un beneficio rimpiazzare un pezzo di codice con una funzione, come in questo esempio:
 
 ```js
 function showPrimes(n) {
@@ -65,7 +65,7 @@ function isPrime(n) {
 }
 ```
 
-Ora possiamo capire il codice più facilmente. La funzione stessa diventa un commento. Questo tipo di codice viene definito *self-descriptive* (auto-descrittivo). 
+Ora possiamo capire il codice più facilmente. La funzione stessa diventa un commento. Questo tipo di codice viene definito *auto-descrittivo*. 
 
 ### Ricetta: creare funzioni
 
@@ -79,7 +79,7 @@ for(let i = 0; i < 10; i++) {
   add(drop, glass);
 }
 
-// qui aggiungiamo della spremuta (juice)
+// qui aggiungiamo della spremuta
 for(let t = 0; t < 3; t++) {
   let tomato = getTomato();
   examine(tomato);
@@ -111,16 +111,16 @@ function addJuice(container) {
 }
 ```
 
-Ripeto nuovamente, le funzioni stesse dicono cosa andranno a fare. Inoltre la struttura del codice è migliore quando è spezzata. E' chiaro cosa ogni funzione faccia, cosa richiede e cosa eventualmente ritorna.
+Ripeto nuovamente, le funzioni stesse dovrebero dire cosa sta succedendo. Non dovrebbe esserci alcun bisogno di commenti. Inoltre anche l'architettura del codice è migliore quando è spezzata. Rende più chiaro lo scopo di ogni funzione.
 
-Nella pratica, non possiamo evitare del tutto i commenti "esplicativi". Ci sono algoritmi molto complesso. E ci sono vari "trucchi" con lo scopo di ottimizzare questo tipo di commenti. In linea di massima dovremmo però cercar di tenere il codice semplice ed auto-descrittivo.
+Nella pratica, non possiamo evitare del tutto i commenti "esplicativi". Ci sono algoritmi molto complessi. E ci sono vari "trucchi" con lo scopo di ottimizzare questo tipo di commenti. In linea di massima dovremmo però cercare di tenere il codice semplice ed auto-descrittivo.
 
 ## Buoni commenti
 
 Quindi, solitamente i commenti esplicativi sono sbagliati. Quali sono allora i commenti giusti?
 
 Descrivere l'architettura
-: Fornire un visuale di alto livello dei componenti, come interagiscono, come si comporta il flusso d'esecuzione in certe situazioni... In breve -- gli "occhi d'aquila" del codice. C'è uno speciale linguaggio schematico [UML](http://wikipedia.org/wiki/Unified_Modeling_Language) per schematizzare ad alto livello. Assolutamente da conoscere.
+: Fornire un visuale di alto livello dei componenti, come interagiscono, come si comporta il flusso d'esecuzione in certe situazioni... In breve -- gli "occhi d'aquila" del codice. Esiste uno speciale linguaggio di schematizzazione, [UML](http://wikipedia.org/wiki/Unified_Modeling_Language) per per la descrizione dell'architettura ad alto livello. Da studiare assolutamente.
 
 Documentare l'utilizzo di una funzione
 : Esiste una particolare sintassi [JSDoc](http://en.wikipedia.org/wiki/JSDoc) per documentare le funzioni: utilizzo, parametri, valori di ritorno.
@@ -141,7 +141,7 @@ Documentare l'utilizzo di una funzione
 
     Questi commenti ci consentono di capire lo scopo della funzione e come utilizzarla correttamente senza guardarne il codice.
 
-    In ogni caso, molti editor come [WebStorm](https://www.jetbrains.com/webstorm/) li comprendono e possono quindi utilizzarli per autocomplete e alcune verifiche automatiche del codice.
+    I molti casi, gli editor come [WebStorm](https://www.jetbrains.com/webstorm/) sono in grado di comprenderli e possono quindi utilizzarli per autocompletamenti e alcune verifiche automatiche del codice.
 
     Ci sono anche tool come [JSDoc 3](https://github.com/jsdoc3/jsdoc) che possono generare documentazione in HTML a partire dai commenti. Puoi scoprire di più riguardo JSDoc su <http://usejsdoc.org/>.
 
@@ -151,20 +151,20 @@ Perché l'azione viene risolta in quel modo?
     Se ci sono diverse modalità di risolvere una determinata azione, perché si è scelta questa? Specialmente quando non risulta la scelta più ovvia.
 
     Senza dei commenti si potrebbero generare le seguenti situazioni:
-    1. Tu (o un tuo collega) apre il codice un pò di tempo dopo, lo guarda e pensa che il codice è "poco ottimale".
-    2. Voi stessi potreste pensare: "Quanto stupido sono stato qui, e quanto intelligente sono adesso", e riscriverla utilizzando "la più ovvia e corretta" variante.
-    3. ...Lo stimolo di riscriverla sarebbe corretto. Ma quando l'avete scritta vi siete resi conto che la soluzione "più ovvia" era effettivamente peggiore. Andando a rileggerla potreste non ricordarvi neanche perché. Quindi dopo averla riscritta vi rendete conto che è meglio tornare indietro, avete sprecato tempo.
+    1. Tu (o un tuo collega) apri il codice un po' di tempo dopo, lo guardi e pensi che il codice è "poco ottimizzato".
+    2. Tu stesso potresti pensare: "Quanto stupido sono stato qui, e quanto intelligente sono adesso", e riscriverla utilizzando la variante "più ovvia e corretta".
+    3. ...Lo stimolo di riscriverla sarebbe forte. Ma quando l'hai scritta ti eri reso conto che la soluzione "più ovvia" era effettivamente peggiore. Andando a rileggerla potresti non ricordarti neanche perché. Quindi dopo averla riscritta ti rendi conto che è meglio tornare indietro, hai sprecato tempo.
 
     Commenti che spiegano la soluzione sono fondamentali. Vi aiutano a sviluppare mantenendo sempre la strada corretta.
 
 Ci sono alcune piccolezze? Dove vengono utilizzate?
-: Se il codice contiene sottigliezze contro-intuitive, vale certamente la pena commentarle.
+: Se il codice contiene sottigliezze contro intuitive, vale certamente la pena commentarle.
 
 ## Riepilogo
 
-Un importante valore che possiede un bravo sviluppatore sono i commenti: la loro presenza o assenza.
+Un importante qualità che deve possedere un bravo sviluppatore, è quella di saper scrivere dei buoni commenti.
 
-I buoni commenti ci consentono di mantenere bene il codice, di poterci tornare dopo un pò di tempo e capire le scelte prese.
+I buoni commenti ci consentono di mantenere il codice in uno stato ottimale, e di poterci tornare dopo un po' di tempo e capire le scelte prese.
 
 **Commenti utili:**
 

1-js/03-code-quality/03-comments/article.md

@@ -14,10 +14,10 @@ Semplicemente una valore "raggiungibile" deve essere accessibile o utilizzabile.
 
     Ad esempio:
 
-    - Variabili locali e parametri correnti della funzione.
-    - Variabili o parametri di altre funzioni che fanno però parte della catena delle chiamate annidate.
+    - Funzioni in esecuzione, i loro parametri e le loro variabi locali.
+    - Funzioni che fanno parte della catena delle chiamate annidate, i loro parametri e le loro variabi locali.
     - Variabili globali.
-    - (ce ne sono altre)
+    - (ce ne sono altri, anche interni)
 
     Questi valori sono detti *radici*.
 

1-js/04-object-basics/03-garbage-collection/article.md

@@ -15,6 +15,11 @@ describe("calculator", function() {
     afterEach(function() {
       prompt.restore();
     });
+    
+    it('the read get two values and saves them as object properties', function () {
+      assert.equal(calculator.a, 2);
+      assert.equal(calculator.b, 3);
+    });
 
     it("the sum is 5", function() {
       assert.equal(calculator.sum(), 5);