You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 1-js/01-getting-started/1-intro/article.md
+4Lines changed: 4 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -109,7 +109,11 @@ Donc, récemment, une pléthore de nouveaux langages sont apparus, qui sont *tra
109
109
110
110
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".
111
111
112
+
<<<<<<< HEAD
112
113
Les exemples les plus courants de ce genre de langages :
114
+
=======
115
+
Examples of such languages:
116
+
>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
113
117
114
118
-[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.
115
119
-[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.
Les trois dernières lignes peuvent nécessiter des explications supplémentaires :
221
221
222
+
<<<<<<<HEAD
222
223
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.
223
224
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.
224
225
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 forcompatibility. 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.
Copy file name to clipboardExpand all lines: 1-js/02-first-steps/07-operators/article.md
+25Lines changed: 25 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -127,11 +127,19 @@ Pourquoi les plus unaires sont-ils appliqués aux valeurs avant les binaires ? C
127
127
128
128
## Précédence des opérateurs
129
129
130
+
<<<<<<<HEAD
130
131
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
131
135
132
136
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.
133
137
138
+
<<<<<<<HEAD
134
139
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
135
143
136
144
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.
137
145
@@ -199,9 +207,15 @@ alert( a ); // 3
199
207
alert( c ); // 0
200
208
```
201
209
210
+
<<<<<<<HEAD
202
211
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`.
203
212
204
213
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
205
219
````
206
220
207
221
## Reste % (Modulo)
@@ -427,10 +441,17 @@ Ici, la première expression `1 + 2` est évaluée mais son résultat n'est pas
427
441
```smart header="La virgule a une très faible précédence"
428
442
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.
429
443
444
+
<<<<<<< HEAD
430
445
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é.
431
446
```
432
447
433
448
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
434
455
435
456
Parfois, les gens l'utilisent dans des constructions plus complexes pour placer plusieurs actions sur une seule ligne.
436
457
@@ -443,4 +464,8 @@ for (*!*a = 1, b = 3, c = a * b*/!*; a < 10; a++) {
443
464
}
444
465
```
445
466
467
+
<<<<<<< HEAD
446
468
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.
Copy file name to clipboardExpand all lines: 1-js/03-code-quality/02-coding-style/article.md
+90Lines changed: 90 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -2,13 +2,21 @@
2
2
3
3
Notre code doit être aussi propre et lisible que possible.
4
4
5
+
<<<<<<< HEAD
5
6
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
6
10
7
11
Une chose à aider est le bon style de code.
8
12
13
+
<<<<<<< HEAD
9
14
## Syntaxe
10
15
11
16
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
12
20
13
21

14
22
<!--
@@ -38,7 +46,13 @@ if (n < 0) {
38
46
39
47
Discutons maintenant des règles et de leurs raisons en détail.
40
48
49
+
<<<<<<< HEAD
41
50
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
42
56
43
57
### Accolades
44
58
@@ -54,7 +68,11 @@ if (condition) {
54
68
}
55
69
```
56
70
71
+
<<<<<<< HEAD
57
72
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
58
76
59
77
Voici les variantes annotées pour que vous puissiez juger de leur lisibilité :
60
78
@@ -74,13 +92,41 @@ if (n < 0) {
74
92
-->
75
93

76
94
95
+
<<<<<<< HEAD
77
96
En résumé :
78
97
- Pour un code vraiment court, une ligne est acceptable: comme `if (cond) return null`.
79
98
- Mais une ligne distincte pour chaque affirmation entre parenthèses est généralement préférable.
80
99
81
100
### Longueur de la ligne
82
101
83
102
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
84
130
85
131
La longueur de ligne maximale est convenue au niveau de l'équipe. C’est généralement 80 ou 120 caractères.
86
132
@@ -129,15 +175,25 @@ Il existe deux types d'indentations :
129
175
130
176
Un point-virgule doit être présent après chaque déclaration. Même si cela pourrait éventuellement être ignoré.
131
177
178
+
<<<<<<<HEAD
132
179
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.
133
180
134
181
À 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
135
187
136
188
### Niveaux d'imbrications
137
189
138
190
Il ne devrait pas y avoir trop de niveaux d'imbrication.
139
191
192
+
<<<<<<<HEAD
140
193
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
141
197
142
198
Au lieu de :
143
199
@@ -199,13 +255,21 @@ function pow(x, n) {
199
255
}
200
256
```
201
257
258
+
<<<<<<<HEAD
202
259
… 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
203
263
204
264
## Placement de Fonction
205
265
206
266
Si vous écrivez plusieurs fonctions "helper" (auxiliaires) et le code pour les utiliser, il existe trois façons de les placer.
207
267
268
+
<<<<<<<HEAD
208
269
1. Fonctions au dessus du code qui les utilise :
270
+
=======
271
+
1. Declare the functions *above* the code that uses them:
272
+
>>>>>>>6bbe0b4313a7845303be835d632ef8e5bc7715cd
209
273
210
274
```js
211
275
// *!*fonctions declarations*/!*
@@ -252,15 +316,23 @@ Si vous écrivez plusieurs fonctions "helper" (auxiliaires) et le code pour les
252
316
253
317
La plupart du temps, la deuxième variante est préférée.
254
318
319
+
<<<<<<< HEAD
255
320
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
256
324
257
325
## Guides de style
258
326
259
327
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.
260
328
261
329
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.
262
330
331
+
<<<<<<<HEAD
263
332
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
264
336
265
337
Par exemple :
266
338
@@ -270,15 +342,27 @@ Par exemple :
270
342
- [StandardJS](https://standardjs.com/)
271
343
- (il y en a plus)
272
344
345
+
<<<<<<< HEAD
273
346
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 ofthischapter. Then you can browse other style guides to pick up more ideas and decide which one you like best.
349
+
>>>>>>>6bbe0b4313a7845303be835d632ef8e5bc7715cd
274
350
275
351
## Linters automatisés
276
352
353
+
<<<<<<<HEAD
277
354
Il existe des outils permettant de vérifier le style de code automatiquement. Ils s'appellent des "linters".
278
355
279
356
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.
280
357
281
358
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
282
366
283
367
Les outils les plus connus sont :
284
368
@@ -326,8 +410,14 @@ De plus, certains IDE prennent en charge le linting nativement, ce qui peut éga
326
410
327
411
## Résumé
328
412
413
+
<<<<<<< HEAD
329
414
Toutes les règles de syntaxe de ce chapitre et les guides de style visent à améliorer la lisibilité, elles sont donc toutes discutables.
330
415
331
416
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
332
422
333
423
Lisez les guides de style pour connaître les dernières idées à ce sujet et suivez celles que vous trouvez les meilleures.
Copy file name to clipboardExpand all lines: 1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/solution.md
+4Lines changed: 4 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,11 @@ Ce que nous avons ici est en fait 3 tests, mais présentés comme une seule fonc
4
4
5
5
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.
6
6
7
+
<<<<<<< HEAD
7
8
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
8
12
9
13
Il serait bien préférable de diviser le test en plusieurs blocs `it` avec des entrées et des sorties clairement écrites.
0 commit comments