Skip to content

Commit 02fb8c4

Browse files
authored
Merge pull request #30 from javascript-tutorial/sync-6bbe0b43
Sync with upstream @ 6bbe0b4
2 parents 189633d + beaa164 commit 02fb8c4

File tree

129 files changed

+845
-513
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

129 files changed

+845
-513
lines changed

1-js/01-getting-started/1-intro/article.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -109,7 +109,11 @@ Donc, récemment, une pléthore de nouveaux langages sont apparus, qui sont *tra
109109

110110
Les outils modernes rendent la [transpilation](https://fr.wiktionary.org/wiki/transpilation) très rapide et transparente, permettant aux développeurs de coder dans une autre langue et de la convertir automatiquement "sous le capot".
111111

112+
<<<<<<< HEAD
112113
Les exemples les plus courants de ce genre de langages :
114+
=======
115+
Examples of such languages:
116+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
113117
114118
- [CoffeeScript](http://coffeescript.org/) est un "sucre syntaxique" pour JavaScript, il introduit une syntaxe plus courte, permettant d’écrire du code plus précis et plus clair. Habituellement, les développeurs Ruby l'aiment bien.
115119
- [TypeScript](http://www.typescriptlang.org/) se concentre sur l'ajout de "typage strict des données" pour simplifier le développement et la prise en charge de systèmes complexes. Il est développé par Microsoft.
Loading
Loading

1-js/02-first-steps/05-types/article.md

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -219,9 +219,15 @@ typeof alert // "function" (3)
219219

220220
Les trois dernières lignes peuvent nécessiter des explications supplémentaires :
221221

222+
<<<<<<< HEAD
222223
1. `Math` est un objet interne au langage qui fournit des opérations mathématiques. Nous allons l'apprendre dans le chapitre <info:number>. Ici, il sert uniquement comme exemple d'un objet.
223224
2. Le résultat de `typeof null` est "object". C'est faux. C'est une erreur officiellement reconnue dans `typeof`, conservée pour compatibilité. Bien sûr, `null` n'est pas un objet. C'est une valeur spéciale avec un type distinct qui lui est propre. Donc, encore une fois, c’est une erreur dans le langage.
224225
3. Le résultat de `typeof alert` est "function", car `alert` est une fonction du langage. Nous étudierons les fonctions dans les chapitres suivants, et nous verrons qu’il n’ya pas de type "fonction" dans le langage. Les fonctions appartiennent au type `object`. Mais `typeof` les traite différemment. Formellement, c'est incorrect, mais très pratique.
226+
=======
227+
1. `Math` is a built-in object that provides mathematical operations. We will learn it in the chapter <info:number>. Here, it serves just as an example of an object.
228+
2. The result of `typeof null` is `"object"`. That's wrong. It is an officially recognized error in `typeof`, kept for compatibility. Of course, `null` is not an object. It is a special value with a separate type of its own. So, again, this is an error in the language.
229+
3. The result of `typeof alert` is `"function"`, because `alert` is a function. We'll study functions in the next chapters where we'll also see that there's no special "function" type in JavaScript. Functions belong to the object type. But `typeof` treats them differently, returning `"function"`. That's not quite correct, but very convenient in practice.
230+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
225231

226232

227233
## Résumé

1-js/02-first-steps/07-operators/article.md

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -127,11 +127,19 @@ Pourquoi les plus unaires sont-ils appliqués aux valeurs avant les binaires ? C
127127

128128
## Précédence des opérateurs
129129

130+
<<<<<<< HEAD
130131
Si une expression a plusieurs opérateurs, l’ordre d’exécution est défini par leur priorité ou, en d’autres termes, il existe un ordre de priorité implicite entre les opérateurs.
132+
=======
133+
If an expression has more than one operator, the execution order is defined by their *precedence*, or, in other words, the default priority order of operators.
134+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
131135

132136
De l'école, nous savons tous que la multiplication dans l'expression `1 + 2 * 2` devrait être calculée avant l'addition. C’est exactement cela la précédence. La multiplication est dite avoir une *précédence supérieure* à l'addition.
133137

138+
<<<<<<< HEAD
134139
Les parenthèses outrepassent toute précédence, donc si nous ne sommes pas satisfaits de l'ordre de traitement, nous pouvons les utiliser, comme: `(1 + 2) * 2`.
140+
=======
141+
Parentheses override any precedence, so if we're not satisfied with the default order, we can use them to change it. For example, write `(1 + 2) * 2`.
142+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
135143

136144
Il y a beaucoup d'opérateurs en JavaScript. Chaque opérateur a un numéro correspondant à sa priorité de précédence. Celui qui est plus haut sur le tableau s'exécute en premier. Si la priorité est la même, l'ordre d'exécution est de gauche à droite.
137145

@@ -199,9 +207,15 @@ alert( a ); // 3
199207
alert( c ); // 0
200208
```
201209

210+
<<<<<<< HEAD
202211
Dans l'exemple ci-dessus, le résultat de `(a = b + 1)` est la valeur attribuée à `a` (c'est-à-dire `3`). Il est ensuite utilisé pour soustraire de `3`.
203212

204213
Code drôle, n'est-ce pas ? Nous devrions comprendre comment cela fonctionne, car parfois nous pouvons le voir dans des bibliothèques tierces, mais nous ne devrions pas écrire quoi que ce soit de similaire nous-mêmes. De telles astuces ne permettent pas de rendre le code plus clair et lisible.
214+
=======
215+
In the example above, the result of expression `(a = b + 1)` is the value which was assigned to `a` (that is `3`). It is then used for further evaluations.
216+
217+
Funny code, isn't it? We should understand how it works, because sometimes we see it in JavaScript libraries, but shouldn't write anything like that ourselves. Such tricks definitely don't make code clearer or readable.
218+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
205219
````
206220

207221
## Reste % (Modulo)
@@ -427,10 +441,17 @@ Ici, la première expression `1 + 2` est évaluée mais son résultat n'est pas
427441
```smart header="La virgule a une très faible précédence"
428442
Veuillez noter que l'opérateur virgule a une précédence très basse, inférieure à `=`, donc les parenthèses sont importantes dans l'exemple ci-dessus.
429443
444+
<<<<<<< HEAD
430445
Sans eux : `a = 1 + 2, 3 + 4` évalue d'abord `+`, additionnant les nombres dans `a = 3, 7`, ensuite l'opérateur d'affectation `=` assigne `a = 3`, puis le nombre après la virgule `7` n'est pas traité c'est ignoré.
431446
```
432447
433448
Pourquoi avons-nous besoin d'un tel opérateur qui jette tout sauf la dernière partie ?
449+
=======
450+
Without them: `a = 1 + 2, 3 + 4` evaluates `+` first, summing the numbers into `a = 3, 7`, then the assignment operator `=` assigns `a = 3`, and the rest is ignored. It's like `(a = 1 + 2), 3 + 4`.
451+
```
452+
453+
Why do we need an operator that throws away everything except the last expression?
454+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
434455

435456
Parfois, les gens l'utilisent dans des constructions plus complexes pour placer plusieurs actions sur une seule ligne.
436457
@@ -443,4 +464,8 @@ for (*!*a = 1, b = 3, c = a * b*/!*; a < 10; a++) {
443464
}
444465
```
445466
467+
<<<<<<< HEAD
446468
Ces astuces sont utilisées dans de nombreux frameworks JavaScript, c’est pourquoi nous les mentionnons. Mais généralement, ils n'améliorent pas la lisibilité du code, nous devrions donc bien réfléchir avant d'écrire comme ça.
469+
=======
470+
Such tricks are used in many JavaScript frameworks. That's why we're mentioning them. But usually they don't improve code readability so we should think well before using them.
471+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
Loading
Loading
Loading
Loading
Loading
Loading

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

Lines changed: 90 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,13 +2,21 @@
22

33
Notre code doit être aussi propre et lisible que possible.
44

5+
<<<<<<< HEAD
56
C’est en fait un art de la programmation -- prendre une tâche complexe et la coder de manière correcte et lisible par l’homme.
7+
=======
8+
That is actually the art of programming -- to take a complex task and code it in a way that is both correct and human-readable. A good code style greatly assists in that.
9+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
610
711
Une chose à aider est le bon style de code.
812

13+
<<<<<<< HEAD
914
## Syntaxe
1015

1116
Un cheatsheet avec les règles (plus de détails ci-dessous) :
17+
=======
18+
Here is a cheat sheet with some suggested rules (see below for more details):
19+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
1220
1321
![](code-style.png)
1422
<!--
@@ -38,7 +46,13 @@ if (n < 0) {
3846

3947
Discutons maintenant des règles et de leurs raisons en détail.
4048

49+
<<<<<<< HEAD
4150
Rien n'est "gravé dans le marbre" ici. Tout est optionnel et peut être modifié: ce sont des règles de codage, pas des dogmes religieux.
51+
=======
52+
```warn header="There are no \"you must\" rules"
53+
Nothing is set in stone here. These are style preferences, not religious dogmas.
54+
```
55+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
4256
4357
### Accolades
4458

@@ -54,7 +68,11 @@ if (condition) {
5468
}
5569
```
5670

71+
<<<<<<< HEAD
5772
Une construction sur une seule ligne est un cas important. Devrions-nous utiliser des crochets ? Si oui, alors où ?
73+
=======
74+
A single-line construct, such as `if (condition) doSomething()`, is an important edge case. Should we use braces at all?
75+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
5876
5977
Voici les variantes annotées pour que vous puissiez juger de leur lisibilité :
6078

@@ -74,13 +92,41 @@ if (n < 0) {
7492
-->
7593
![](figure-bracket-style.png)
7694

95+
<<<<<<< HEAD
7796
En résumé :
7897
- Pour un code vraiment court, une ligne est acceptable: comme `if (cond) return null`.
7998
- Mais une ligne distincte pour chaque affirmation entre parenthèses est généralement préférable.
8099

81100
### Longueur de la ligne
82101

83102
La longueur maximale de la ligne doit être limitée. Personne n'aime suivre les yeux sur une longue ligne horizontale. C’est mieux de la scinder.
103+
=======
104+
### Line Length
105+
106+
No one likes to read a long horizontal line of code. It's best practice to split them.
107+
108+
For example:
109+
```js
110+
// backtick quotes ` allow to split the string into multiple lines
111+
let str = `
112+
Ecma International's TC39 is a group of JavaScript developers,
113+
implementers, academics, and more, collaborating with the community
114+
to maintain and evolve the definition of JavaScript.
115+
`;
116+
```
117+
118+
And, for `if` statements:
119+
120+
```js
121+
if (
122+
id === 123 &&
123+
moonPhase === 'Waning Gibbous' &&
124+
zodiacSign === 'Libra'
125+
) {
126+
letTheSorceryBegin();
127+
}
128+
```
129+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
84130
85131
La longueur de ligne maximale est convenue au niveau de l'équipe. C’est généralement 80 ou 120 caractères.
86132

@@ -129,15 +175,25 @@ Il existe deux types d'indentations :
129175

130176
Un point-virgule doit être présent après chaque déclaration. Même si cela pourrait éventuellement être ignoré.
131177

178+
<<<<<<< HEAD
132179
Il y a des langages où le point-virgule est vraiment optionnel. Il est donc rarement utilisé. Mais dans JavaScript, il y a peu de cas où un saut de ligne n'est parfois pas interprété comme un point-virgule. Cela laisse place à des erreurs de programmation.
133180
134181
À mesure que vous devenez plus mature en tant que programmeur, vous pouvez choisir un style sans point-virgule, comme [StandardJS](https://standardjs.com/), mais c’est seulement lorsque vous connaissez bien JavaScript et que vous comprenez les pièges possibles.
182+
=======
183+
There are languages where a semicolon is truly optional and it is rarely used. In JavaScript, though, there are cases where a line break is not interpreted as a semicolon, leaving the code vulnerable to errors. See more about that in the chapter <info:structure#semicolon>.
184+
185+
If you're an experienced JavaScript programmer, you may choose a no-semicolon code style like [StandardJS](https://standardjs.com/). Otherwise, it's best to use semicolons to avoid possible pitfalls. The majority of developers put semicolons.
186+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
135187

136188
### Niveaux d'imbrications
137189
138190
Il ne devrait pas y avoir trop de niveaux d'imbrication.
139191

192+
<<<<<<< HEAD
140193
C’est parfois une bonne idée d’utiliser la directive ["continue"](info:while-for#continue) dans la boucle pour éviter l'imbrication supplémentaire `if(..) { ... }` :
194+
=======
195+
For example, in the loop, it's sometimes a good idea to use the ["continue"](info:while-for#continue) directive to avoid extra nesting.
196+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
141197

142198
Au lieu de :
143199

@@ -199,13 +255,21 @@ function pow(x, n) {
199255
}
200256
```
201257

258+
<<<<<<< HEAD
202259
… Mais le second est plus lisible, car le "cas marginal" de `n < 0` est traité tôt, et nous avons ensuite le flux de code "principal", sans imbrication supplémentaire.
260+
=======
261+
The second one is more readable because the "special case" of `n < 0` is handled early on. Once the check is done we can move on to the "main" code flow without the need for additional nesting.
262+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
203263

204264
## Placement de Fonction
205265

206266
Si vous écrivez plusieurs fonctions "helper" (auxiliaires) et le code pour les utiliser, il existe trois façons de les placer.
207267

268+
<<<<<<< HEAD
208269
1. Fonctions au dessus du code qui les utilise :
270+
=======
271+
1. Declare the functions *above* the code that uses them:
272+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
209273

210274
```js
211275
// *!*fonctions declarations*/!*
@@ -252,15 +316,23 @@ Si vous écrivez plusieurs fonctions "helper" (auxiliaires) et le code pour les
252316
253317
La plupart du temps, la deuxième variante est préférée.
254318
319+
<<<<<<< HEAD
255320
C’est parce qu’en lisant un code, nous voulons d’abord savoir "ce qu’il fait". Si le code commence en premier, alors il fournit cette information. Et puis peut-être n’aurons-nous pas besoin de lire les fonctions du tout, surtout si leur nom correspond à ce qu’elles font.
321+
=======
322+
That's because when reading code, we first want to know *what it does*. If the code goes first, then it becomes clear from the start. Then, maybe we won't need to read the functions at all, especially if their names are descriptive of what they actually do.
323+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
256324
257325
## Guides de style
258326
259327
Un guide de style contient des règles générales sur "comment écrire": les quotes à utiliser, le nombre d'espaces à mettre en retrait, l'emplacement des sauts de ligne, etc. Beaucoup de petites choses.
260328
261329
Au total, lorsque tous les membres d'une équipe utilisent le même guide de style, le code est uniforme. Peu importe qui l’a écrit, c’est toujours le même style.
262330

331+
<<<<<<< HEAD
263332
Certes, une équipe peut réfléchir à un guide de style. Mais dorénavant, il n’est plus nécessaire de le faire. Il existe de nombreux guides de style éprouvés et faciles à adopter.
333+
=======
334+
Of course, a team can always write their own style guide, but usually there's no need to. There are many existing guides to choose from.
335+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
264336
265337
Par exemple :
266338
@@ -270,15 +342,27 @@ Par exemple :
270342
- [StandardJS](https://standardjs.com/)
271343
- (il y en a plus)
272344
345+
<<<<<<< HEAD
273346
Si vous êtes un développeur novice, vous pouvez commencer par le cheatsheet ci-dessus dans le chapitre, puis consulter les guides de style pour découvrir les principes communs et éventuellement en choisir un.
347+
=======
348+
If you're a novice developer, start with the cheat sheet at the beginning of this chapter. Then you can browse other style guides to pick up more ideas and decide which one you like best.
349+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
274350

275351
## Linters automatisés
276352

353+
<<<<<<< HEAD
277354
Il existe des outils permettant de vérifier le style de code automatiquement. Ils s'appellent des "linters".
278355
279356
Ce qui est génial avec eux, c'est que la vérification du style trouve également des bugs, comme une faute de frappe dans une variable ou un nom de fonction.
280357

281358
Il est donc recommandé d’en installer un, même si vous ne voulez pas vous en tenir à un «style de code». Ils aident à trouver des fautes de frappe - et cela suffit déjà.
359+
=======
360+
Linters are tools that can automatically check the style of your code and make improving suggestions.
361+
362+
The great thing about them is that style-checking can also find some bugs, like typos in variable or function names. Because of this feature, using a linter is recommended even if you don't want to stick to one particular "code style".
363+
364+
Here are some well-known linting tools:
365+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
282366

283367
Les outils les plus connus sont :
284368

@@ -326,8 +410,14 @@ De plus, certains IDE prennent en charge le linting nativement, ce qui peut éga
326410
327411
## Résumé
328412
413+
<<<<<<< HEAD
329414
Toutes les règles de syntaxe de ce chapitre et les guides de style visent à améliorer la lisibilité, elles sont donc toutes discutables.
330415
331416
Lorsque nous réfléchissons à "comment écrire mieux ?", Le seul critère est "qu'est-ce qui rend le code plus lisible et plus facile à comprendre ? qu'est-ce qui aide à éviter les erreurs ?". C’est l’essentiel à garder à l’esprit lors du choix du style ou de la question de savoir lequel est le meilleur.
417+
=======
418+
All syntax rules described in this chapter (and in the style guides referenced) aim to increase the readability of your code. All of them are debatable.
419+
420+
When we think about writing "better" code, the questions we should ask ourselves are: "What makes the code more readable and easier to understand?" and "What can help us avoid errors?" These are the main things to keep in mind when choosing and debating code styles.
421+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
332422
333423
Lisez les guides de style pour connaître les dernières idées à ce sujet et suivez celles que vous trouvez les meilleures.
Loading
Loading

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

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,11 @@ Comme nous le savons du chapitre <info:structure>, les commentaires peuvent êtr
44

55
Nous les utilisons normalement pour décrire comment et pourquoi le code fonctionne.
66

7+
<<<<<<< HEAD
78
De prime abord, les commentaires peuvent sembler évidents, mais les novices en programmation se trompent généralement.
9+
=======
10+
At first sight, commenting might be obvious, but novices in programming usually get it wrong.
11+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
812
913
## Mauvais commentaires
1014

@@ -18,7 +22,11 @@ complex;
1822
code;
1923
```
2024

25+
<<<<<<< HEAD
2126
Mais en bon code, le nombre de ces commentaires "explicatifs" devrait être minime. Sérieusement, le code devrait être facile à comprendre sans eux.
27+
=======
28+
But in good code, the amount of such "explanatory" comments should be minimal. Seriously, the code should be easy to understand without them.
29+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
2230
2331
Il existe une excellente règle à ce sujet: "Si le code est si peu clair qu’il nécessite un commentaire, il devrait peut-être être réécrit".
2432

1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/solution.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,11 @@ Ce que nous avons ici est en fait 3 tests, mais présentés comme une seule fonc
44

55
Parfois, il est plus facile d’écrire de cette façon, mais si une erreur se produit, ce qui a mal tourné est beaucoup moins évident.
66

7+
<<<<<<< HEAD
78
Si une erreur survient dans un flux d’exécution complexe, nous devrons bien comprendre les données à ce stade. Nous devrons en fait *déboguer le test*.
9+
=======
10+
If an error happens in the middle of a complex execution flow, then we'll have to figure out the data at that point. We'll actually have to *debug the test*.
11+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
812
913
Il serait bien préférable de diviser le test en plusieurs blocs `it` avec des entrées et des sorties clairement écrites.
1014

0 commit comments

Comments
 (0)