merging all conflicts

Author: root

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

@@ -105,7 +105,11 @@ Javascript – це єдина браузерна технологія, яка 
 
 Сучасні інструменти роблять транспіляцію дуже швидкою і прозорою, дозволяючи розробникам писати код іншою мовою і автоматично конвертувати його "під капотом".
 
+<<<<<<< HEAD
 Приклади таких мов:
+=======
+Examples of such languages:
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 - [CoffeeScript](http://coffeescript.org/) це "синтаксичний цукор" поверх JavaScript. Вона вводить більш короткий синтаксис, дозволяючи нам писати більш чіткий і точний код. Зазвичай, програмісти на Ruby люблять її.
 - [TypeScript](http://www.typescriptlang.org/) зосереджена на додаванні "строгої типізації даних", щоб спростити розробку і підтримку складних систем. ЇЇ розробляє Microsoft.

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

@@ -219,9 +219,15 @@ typeof alert // "function"  (3)
 
 Останні три рядки можуть потребувати додаткового пояснення:
 
+<<<<<<< HEAD
 1. `Math` — це вбудований об'єкт, який забезпечує математичні операції.
 2. Рзультатом `typeof null` є `"object"`. Це неправильно. Це офіційно визнана помилка в "typeof", що зберігається для сумісності. Звичайно, `null` не є об'єктом. Це особливе значення з власним типом. Отже, знову ж таки, це помилка в мові.
 3. Результатом `typeof alert` є `"function"`, тому що `alert` — це функція мови. Ми будемо вивчати функції в наступних розділах, де ми побачимо, що в JavaScript немає спеціального типу "function". Функції належать до типу об'єкта. Але `typeof` трактує їх по-різному. Формально це неправильно, але дуже зручно на практиці.
+=======
+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.
+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.
+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.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 
 ## Підсумки

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

@@ -127,11 +127,19 @@ alert( +apples + +oranges ); // 5
 
 ## Пріоритет оператора
 
+<<<<<<< HEAD
 Якщо вираз має більше одного оператора, порядок виконання визначається їх *пріоритетом*, або, іншими словами, неявним порядком пріоритетів операторів.
+=======
+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.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Зі школи ми всі знаємо, що множення у виразі `1 + 2 * 2` повинно бути обчислене перед додаванням. Саме це і є пріоритетом. Кажуть, що множення має *вищий пріоритет*, ніж додавання.
 
+<<<<<<< HEAD
 Дужки перевизначають будь-який пріоритет, тому, якщо ми не задоволенні неявним приорітетом, ми можемо використовувати дужки, щоб змінити його. Наприклад: `(1 + 2) * 2`.
+=======
+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`.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 У JavaScript є багато операторів. Кожен оператор має відповідний номер пріоритету. Першим виконується той оператор, який має найбільший номер пріоритету. Якщо пріоритет є однаковим, порядок виконання — зліва направо.
 
@@ -199,9 +207,15 @@ alert( a ); // 3
 alert( c ); // 0
 ```
 
+<<<<<<< HEAD
 У наведенному вище прикладі результат `(a = b + 1)` є значенням, яке присвоюється змінній `a` (тобто `3`). Потім воно використовується для віднімання від `3`.
 
 Смішний код, чи не так? Ми повинні зрозуміти, як це працює, бо іноді ми бачимо подібне у сторонніх бібліотеках, але самі не повинні писати нічого подібного. Такі трюки, безумовно, не роблять код більш ясним або читабельним.
+=======
+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.
+
+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.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 ````
 
 ## Залишок %
@@ -427,10 +441,17 @@ alert( a ); // 7 (результат обчислення 3 + 4)
 ```smart header="Кома має дуже низький пріоритет"
 Зверніть увагу, що оператор кома має дуже низький пріоритет, нижчий за `=`, тому дужки є важливими в наведеному вище прикладі.
 
+<<<<<<< HEAD
 Без них: `a = 1 + 2, 3 + 4` обчислює спочатку `+`, підсумовуючи числа у `a = 3, 7`, потім оператор присвоєння `=` присвоює    `a = 3`, і нарешті число після коми, `7`, не обробляється та ігнорується.
 ```
 
 Чому нам потрібен оператор, що викидає все, окрім останньої частини?
+=======
+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`.
+```
+
+Why do we need an operator that throws away everything except the last expression?
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Іноді люди використовують його в більш складних конструкціях, щоб помістити кілька дій в один рядок.
 
@@ -443,4 +464,8 @@ for (*!*a = 1, b = 3, c = a * b*/!*; a < 10; a++) {
 }
 ```
 
+<<<<<<< HEAD
 Такі трюки використовуються в багатьох фреймворках JavaScript. Саме тому ми їх згадуємо. Але, як правило, вони не покращують читабельність коду, тому ми повинні добре подумати перед їх використанням.
+=======
+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.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd

1-js/03-code-quality/01-debugging-chrome/chrome-open-sources.png

@@ -2,11 +2,11 @@
 
 Our code must be as clean and easy to read as possible.
 
-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.
+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.  
 
 ## Syntax
 
-Here is a cheatsheet with some suggested rules (see below for more details):
+Here is a cheat sheet with some suggested rules (see below for more details):
 
 ![](code-style.png)
 <!--
@@ -36,7 +36,7 @@ if (n < 0) {
 
 Now let's discuss the rules and reasons for them in detail.
 
-```warn header="Irony Detected"
+```warn header="There are no \"you must\" rules"
 Nothing is set in stone here. These are style preferences, not religious dogmas.
 ```
 
@@ -52,7 +52,7 @@ if (condition) {
 }
 ```
 
-A single-line construct is an important edge case. Should we use brackets at all? If yes, then where?
+A single-line construct, such as `if (condition) doSomething()`, is an important edge case. Should we use braces at all?
 
 Here are the annotated variants so you can judge their readability for yourself:
 
@@ -72,13 +72,31 @@ if (n < 0) {
 -->
 ![](figure-bracket-style.png)
 
-In summary:
-- For very short code, one line is acceptable. For example: `if (cond) return null`.
-- But a separate line for each statement in brackets is usually easier to read.
-
 ### Line Length
 
-No one likes to read a long horizontal line of code. It's best practice to split them up and limit the length of your lines.
+No one likes to read a long horizontal line of code. It's best practice to split them.
+
+For example:
+```js
+// backtick quotes ` allow to split the string into multiple lines
+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.
+`;
+```
+
+And, for `if` statements:
+
+```js
+if (
+  id === 123 &&
+  moonPhase === 'Waning Gibbous' &&
+  zodiacSign === 'Libra'
+) {
+  letTheSorceryBegin();
+}
+```
 
 The maximum line length should be agreed upon at the team-level. It's usually 80 or 120 characters.
 
@@ -127,15 +145,15 @@ There are two types of indents:
 
 A semicolon should be present after each statement, even if it could possibly be skipped.
 
-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.
+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>.
 
-As you become more mature as a programmer, you may choose a no-semicolon style like [StandardJS](https://standardjs.com/). Until then, it's best to use semicolons to avoid possible pitfalls.
+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.
 
 ### Nesting Levels
 
 Try to avoid nesting code too many levels deep.
 
-Sometimes it's a good idea to use the ["continue"](info:while-for#continue) directive in a loop to avoid extra nesting.
+For example, in the loop, it's sometimes a good idea to use the ["continue"](info:while-for#continue) directive to avoid extra nesting.
 
 For example, instead of adding a nested `if` conditional like this:
 
@@ -197,13 +215,13 @@ function pow(x, n) {
 }
 ```
 
-The second one is more readable because the "edge 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.
+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.
 
 ## Function Placement
 
 If you are writing several "helper" functions and the code that uses them, there are three ways to organize the functions.
 
-1. Functions declared above the code that uses them:
+1. Declare the functions *above* the code that uses them:
 
     ```js
     // *!*function declarations*/!*
@@ -249,15 +267,15 @@ If you are writing several "helper" functions and the code that uses them, there
 
 Most of time, the second variant is preferred.
 
-That's because when reading code, we first want to know *what it does*. If the code goes first, then it provides that information. Then, maybe we won't need to read the functions at all, especially if their names are descriptive of what they actually do.
+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.
 
 ## Style Guides
 
 A style guide contains general rules about "how to write" code, e.g. which quotes to use, how many spaces to indent, where to put line breaks, etc. A lot of minor things.
 
 When all members of a team use the same style guide, the code looks uniform, regardless of which team member wrote it.
 
-Of course, a team can always write their own style guide. Most of the time though, there's no need to. There are many existing tried and true options to choose from, so adopting one of these is usually your best bet.
+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.
 
 Some popular choices:
 
@@ -267,15 +285,15 @@ Some popular choices:
 - [StandardJS](https://standardjs.com/)
 - (plus many more)
 
-If you're a novice developer, start with the cheatsheet at the beginning of this chapter. Once you've mastered that you can browse other style guides to pick up common principles and decide which one you like best.
+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.
 
 ## Automated Linters
 
-Linters are tools that can automatically check the style of your code and make suggestions for refactoring.
+Linters are tools that can automatically check the style of your code and make improving suggestions.
 
-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, installing a linter is recommended even if you don't want to stick to one particular "code style".
+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".
 
-Here are the most well-known linting tools:
+Here are some well-known linting tools:
 
 - [JSLint](http://www.jslint.com/) -- one of the first linters.
 - [JSHint](http://www.jshint.com/) -- more settings than JSLint.
@@ -317,8 +335,8 @@ Also certain IDEs have built-in linting, which is convenient but not as customiz
 
 ## Summary
 
-All syntax rules described in this chapter (and in the style guides referenced) aim to increase the readability of your code, but all of them are debatable.
+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.
 
-When we think about writing "better" code, the questions we should ask 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.
+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.
 
 Reading popular style guides will allow you to keep up to date with the latest ideas about code style trends and best practices.