From c0db2c2424f343578b289bfeb5c95d26d1794be9 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Wed, 26 Feb 2020 03:37:23 +0200 Subject: [PATCH 01/25] Translate Code Style section --- .../1-style-errors/solution.md | 27 +-- .../02-coding-style/1-style-errors/task.md | 6 +- .../02-coding-style/article.md | 190 +++++++++--------- .../02-coding-style/code-style.svg | 2 +- 4 files changed, 114 insertions(+), 111 deletions(-) diff --git a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md index 764e36c63..9945e7807 100644 --- a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md +++ b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md @@ -1,29 +1,30 @@ +Ви можете You could note the following: ```js no-beautify -function pow(x,n) // <- no space between arguments -{ // <- figure bracket on a separate line - let result=1; // <- no spaces before or after = - for(let i=0;i -Now let's discuss the rules and reasons for them in detail. +Давайте розберемо ці правила і причини їх з'явлення більш детально. -```warn header="There are no \"you must\" rules" -Nothing is set in stone here. These are style preferences, not religious dogmas. +```warn header="Немає обов'язкових правил" +Залізних правил немає. Все це стильові уподобання, а не релігійні догми. ``` -### Curly Braces +### Фігурні дужки -In most JavaScript projects curly braces are written in "Egyptian" style with the opening brace on the same line as the corresponding keyword -- not on a new line. There should also be a space before the opening bracket, like this: +У більшості JavaScript проектів фігурні дужки написані у так званому "Єгипетському" стилі з відкриваючою дужкою на тому ж рядку, що й відповідне ключове слово -- не на новому рядку. Також потрібно додавати пробіл перед відкриваючою дужкою, наприклад: ```js if (condition) { @@ -52,47 +52,48 @@ if (condition) { } ``` -A single-line construct, such as `if (condition) doSomething()`, is an important edge case. Should we use braces at all? +Чи потрібно ставити дужки, коли конструкція складається з одного рядка, наприклад `if (condition) doSomething()`? -Here are the annotated variants so you can judge their readability for yourself: +Нижче наведені різні варіанти розташування дужок з коментарями, щоб ви змогли самостійно вирішити який варіант є найбільш читабельним. -1. 😠 Beginners sometimes do that. Bad! Curly braces are not needed: +1. 😠 Початківці іноді викорустовують таку конструкцію. Це поганий приклад, фігурні дужки не потрібні: ```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. 😠 Ніколи не розподіляйте конструкцію на декілька рядків без фігурних дужок - дуже легко зробити помилку при додаванні нового рядка: ```js if (n < 0) alert(`Power ${n} is not supported`); ``` -3. 😏 One line without braces - acceptable, if it's short: +3. 😏 Писати в один рядок без дужок є прийнятним варіантом, якщо рядок короткий: ```js if (n < 0) alert(`Power ${n} is not supported`); ``` -4. 😃 The best variant: +4. 😃 Найкращий варіант: ```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. +Для дуже короткого коду один рядок є прийнятним, напприклад `if (cond) return null`. Але блок коду (останній варінт) зазвчай є більш читабельним. -### Line Length +### Довжина рядку -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. + Робоча група TC39 організації ECMA International - + це група JavaScript-розробників, спеціалістів з інтеграції, + науковців, і т.д., які працюють разом зі спільнотою + над підтримкою та розвитком мови JavaScript. `; ``` -And, for `if` statements: +Або для `if`: ```js if ( @@ -104,23 +105,23 @@ if ( } ``` -The maximum line length should be agreed upon at the team-level. It's usually 80 or 120 characters. +Максимальну довжину рядку визначається командою. Зазвичай це `80` або `120` символів. -### Indents +### Відступи -There are two types of indents: +Є два види відступів -- **Horizontal indents: 2 or 4 spaces.** +- **Горизонтальні відступи: 2 або 4 пробіли.** - A horizontal indentation is made using either 2 or 4 spaces or the horizontal tab symbol (key `key:Tab`). Which one to choose is an old holy war. Spaces are more common nowadays. + Горизонтальний відступ робиться за допогою двох або чотирьох пробілів, або за допомогою табуляції (клавіша `key:Tab`). Який відступ вибирати - вирішувати вам. Відступ з пробілам більш поширений на сьогодні. - One advantage of spaces over tabs is that spaces allow more flexible configurations of indents than the tab symbol. + Однією з переваг пробілів є те, що пробіли дозволяють більш гнучку конфігурацію відступів, ніж табуляція. - For instance, we can align the arguments with the opening bracket, like this: + Наприклад, ми можемо вирівняти аругменти відносно відкритої дужки: ```js no-beautify show(parameters, - aligned, // 5 spaces padding at the left + aligned, // 5 пробілів зліва one, after, another @@ -129,9 +130,9 @@ There are two types of indents: } ``` -- **Vertical indents: empty lines for splitting code into logical blocks.** +- **Вертикальні відступи: пусті рядки для розподілу коду на "логічні блоки" .** - Even a single function can often be divided into logical blocks. In the example below, the initialization of variables, the main loop and returning the result are split vertically: +  Навіть окрема фунція може бути зазвичай розподілена на логічні блоки. У наведенному нижче прикладі, ініціалізація змінних, основний цикл та повернення результату розподілені вертикально: ```js function pow(x, n) { @@ -145,51 +146,51 @@ There are two types of indents: } ``` - Insert an extra newline where it helps to make the code more readable. There should not be more than nine lines of code without a vertical indentation. + Вставляйте додаткову строку в тому випадку, коли це допомагає зробити код більш зрозумілим. Не повинно бути більше дев'яти строк коду підряд без вертикального розподілу. -### Semicolons +### Крапка з комою -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. See more about that in the chapter . +Є мови програмування, у яких крапка з комою є дійсно необов'язковими і рідко використовуються. Проте у JavaScript є ситуації коли перенос строки не інтерпретується як крапка з комою, залишаючи код вразливим до помилок. Більше детально про це знайдете у розділі . -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. +Якщо ви досвідчений JavaScript програміст, ви можете обрати стиль коду без крапки з комою, наприклад [StandardJS](https://standardjs.com/). Інакше, краще використовувати крапку з комою для того, щоб уникнути підводних каменів. Більшість розробників використовують крапку з комою. -### Nesting Levels +### Рівні вкладеності -Try to avoid nesting code too many levels deep. +Намагайтесь уникати велику кількість рівнів вкладеності. -For example, in the loop, it's sometimes a good idea to use the [`continue`](info:while-for#continue) directive to avoid extra nesting. +Наприклад, у циклі, іноді хорошим варіантом є використання директиви [`continue`](info:while-for#continue) для уникнення вкладенності. -For example, instead of adding a nested `if` conditional like this: +Наприклад, замість додавання умови `if`: ```js for (let i = 0; i < 10; i++) { if (cond) { - ... // <- one more nesting level + ... // <- ще один рівень вкладеності } } ``` -We can write: +ми можемо написати: ```js for (let i = 0; i < 10; i++) { if (!cond) *!*continue*/!*; - ... // <- no extra nesting level + ... // <- немає вкладеності } ``` -A similar thing can be done with `if/else` and `return`. +Схожим чином ми можемо змінити `if/else` та `return`. -For example, two constructs below are identical. +Наприклад, дві конструкції нижче є ідентичними. -Option 1: +Перша: ```js function pow(x, n) { if (n < 0) { - alert("Negative 'n' not supported"); + alert("Від'ємні значення 'n' не підтримуються"); } else { let result = 1; @@ -202,12 +203,12 @@ function pow(x, n) { } ``` -Option 2: +Друга: ```js function pow(x, n) { if (n < 0) { - alert("Negative 'n' not supported"); + alert("Від'ємні значення 'n' не підтримуються"); return; } @@ -221,16 +222,16 @@ function pow(x, n) { } ``` -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. +Друга конструкція є більш зрозумілою, тому що умова `n < 0` обробляється з самого початку. Коли перевірка закінчена ми можемо переходити до "говоного" коду без потреби у додатковому рівні вкладеності. -## Function Placement +## Розташування Функцій -If you are writing several "helper" functions and the code that uses them, there are three ways to organize the functions. +Якщо ви пишете декілька допоміжних функцій і код, що їх виростуває, є три способи організувати функції. -1. Declare the functions *above* the code that uses them: +1. Оголосити функції *перед* кодом, що їх використовує: ```js - // *!*function declarations*/!* + // *!*оголошення функій*/!* function createElement() { ... } @@ -243,20 +244,20 @@ If you are writing several "helper" functions and the code that uses them, there ... } - // *!*the code which uses them*/!* + // *!*код, що їх використовує*/!* let elem = createElement(); setHandler(elem); walkAround(); ``` -2. Code first, then functions +2. Спочатку код, потім функції ```js - // *!*the code which uses the functions*/!* + // *!*код, що використовує функції*/!* let elem = createElement(); setHandler(elem); walkAround(); - // --- *!*helper functions*/!* --- + // --- *!*допоміжні функції*/!* --- function createElement() { ... } @@ -269,54 +270,55 @@ If you are writing several "helper" functions and the code that uses them, there ... } ``` -3. Mixed: a function is declared where it's first used. +3. Зміжаний варінт: функція оголошена там, де вона вперше використовується. -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 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, the maximal line length, 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, but usually there's no need to. There are many existing guides to choose from. +Звичайно, кожна команда може завжди створити свій посібник зі стилю, але зазвичай в тому не має потреби. Є багато існуючих посібників серед який можна вибрати. -Some popular choices: +Деякі популярні посібники: - [Google JavaScript Style Guide](https://google.github.io/styleguide/javascriptguide.xml) - [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) - [Idiomatic.JS](https://github.com/rwaldron/idiomatic.js) - [StandardJS](https://standardjs.com/) -- (plus many more) +- (і ще багато інших) -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 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, using a linter is recommended even if you don't want to stick to one particular "code style". +Саме чудове в них є те, зо вони можуть також знайти деякі програмні помилки, наприклад друкарську помилку у назві змінної чи функції. Завдяки цій особливості, рекомендують використовувати лінтер навіть тоді, коли ви не збираєтесь дотримуватись якогось конкретного "стилю коду". -Here are some well-known linting tools: +Ось декілька +Here are some добре відомих засобів для перевірки: -- [JSLint](http://www.jslint.com/) -- one of the first linters. -- [JSHint](http://www.jshint.com/) -- more settings than JSLint. -- [ESLint](http://eslint.org/) -- probably the newest one. +- [JSLint](http://www.jslint.com/) -- один з перших лінтерів. +- [JSHint](http://www.jshint.com/) -- має більше налаштувань ніж JSLint. +- [ESLint](http://eslint.org/) -- напевно, найсучасніший лінтер. -All of them can do the job. The author uses [ESLint](http://eslint.org/). +Всі вони роблять свою справу. Автор використовує [ESLint](http://eslint.org/). -Most linters are integrated with many popular editors: just enable the plugin in the editor and configure the style. +Більшість лінтерів інтегровані у популярні редактори: просто ввімкнуть відповідний плагін у редакторі і налаштуйте стиль. -For instance, for ESLint you should do the following: +Наприклад, для ESLint вам потрібно зробити наступне: -1. Install [Node.js](https://nodejs.org/). -2. Install ESLint with the command `npm install -g eslint` (npm is a JavaScript package installer). -3. Create a config file named `.eslintrc` in the root of your JavaScript project (in the folder that contains all your files). -4. Install/enable the plugin for your editor that integrates with ESLint. The majority of editors have one. +1. Встановіть [Node.js](https://nodejs.org/). +2. Встановіть ESLint використовуючи команду `npm install -g eslint` (npm це менеджер JavaScript пакетів(модулів)). +3. Створіть файл конфігурації `.eslintrc` у корні вашого JavaScript проекту (у директорії, що містить всі ваші файли). +4. Встановіть/ввімкніть плагін для вашого редактору, який інтегрується з ESLint. Більшість редакторів мають такий плагін. -Here's an example of an `.eslintrc` file: +Ось приклад файлу `.eslintrc`: ```js { @@ -333,16 +335,16 @@ Here's an example of an `.eslintrc` file: } ``` -Here the directive `"extends"` denotes that the configuration is based on the "eslint:recommended" set of settings. After that, we specify our own. +Директива `"extends"` означає, що конфігурація базується на наборі налаштувань "eslint:recommended". Після цього, ви вказуєте ваші власні. -It is also possible to download style rule sets from the web and extend them instead. See for more details about installation. +Крім того, можна завантажити набори правил з мережі та розширити їх. Дивіться для отримання більш детальної інструкції зі встановлення. -Also certain IDEs have built-in linting, which is convenient but not as customizable as ESLint. +Також, деякі середовища розробки (IDE) мають вбудовані засоби первірки коду, що є зручним, але не таким гнучким в налаштуванні рішенням, як ESLint. -## Summary +## Висновки -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 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. +Читання популярних посібників зі стилю коду дозволить вам бути в курсі найкращих практик та останніх ідей щодо стилю коду. diff --git a/1-js/03-code-quality/02-coding-style/code-style.svg b/1-js/03-code-quality/02-coding-style/code-style.svg index bd62691c6..79626a4bd 100644 --- a/1-js/03-code-quality/02-coding-style/code-style.svg +++ b/1-js/03-code-quality/02-coding-style/code-style.svg @@ -1 +1 @@ -2No space between the function name and parentheses between the parentheses and the parameterIndentation 2 spacesA space after for/if/while…} else { without a line breakSpaces around a nested callAn empty line between logical blocksLines are not very longA semicolon ; is mandatorySpaces around operatorsCurly brace { on the same line, after a spaceA space between parametersA space between parameters \ No newline at end of file +2Немає пробілу між ім'ям функції і круглими дужками та між круглими дужками та параметромВідступ 2 пробіли Пробіл після for/if/while…} else { на одному рядкуПробіли навколо вкладеного викликуПустий рядок між логічними блокамиРядки короткіКрапка з комою ; є обов'язковоюПробіли навколо операторівФігурна дужка { на тому ж рядку, після пробілуПробіл між параметрами Пробіл між параметрами \ No newline at end of file From 48299ae9d5763b318d2f8a5f874a13cdf7f0b1f7 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Wed, 26 Feb 2020 03:44:13 +0200 Subject: [PATCH 02/25] Fixed mistake in solution translation --- .../03-code-quality/02-coding-style/1-style-errors/solution.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md index 9945e7807..699a426e1 100644 --- a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md +++ b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md @@ -1,6 +1,5 @@ -Ви можете -You could note the following: +Ви можете зробити наступні відмітки: ```js no-beautify function pow(x,n) // <- немає пробілу між аргументами From 593e2e194dfd50b077f12287243207e8cd316d1b Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:14:33 +0200 Subject: [PATCH 03/25] Update 1-js/03-code-quality/02-coding-style/article.md Co-Authored-By: Taras --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index 0425625f4..2aaef14ae 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -314,7 +314,7 @@ Here are some добре відомих засобів для перевірки Наприклад, для ESLint вам потрібно зробити наступне: 1. Встановіть [Node.js](https://nodejs.org/). -2. Встановіть ESLint використовуючи команду `npm install -g eslint` (npm це менеджер JavaScript пакетів(модулів)). +2. Встановіть ESLint, використовуючи команду `npm install -g eslint` (npm – це менеджер JavaScript пакетів (модулів)). 3. Створіть файл конфігурації `.eslintrc` у корні вашого JavaScript проекту (у директорії, що містить всі ваші файли). 4. Встановіть/ввімкніть плагін для вашого редактору, який інтегрується з ESLint. Більшість редакторів мають такий плагін. From b719b94669dc47d009c2633316131ee568dee326 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:14:48 +0200 Subject: [PATCH 04/25] Update 1-js/03-code-quality/02-coding-style/article.md Co-Authored-By: Taras --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index 2aaef14ae..c4d18bd24 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -339,7 +339,7 @@ Here are some добре відомих засобів для перевірки Крім того, можна завантажити набори правил з мережі та розширити їх. Дивіться для отримання більш детальної інструкції зі встановлення. -Також, деякі середовища розробки (IDE) мають вбудовані засоби первірки коду, що є зручним, але не таким гнучким в налаштуванні рішенням, як ESLint. +Також, деякі середовища розробки (IDE) мають вбудовані засоби первірки коду, що є зручним, але не таким гнучким в налаштуванні рішенням, як ESLint. ## Висновки From 3f363f2794b404c8752b4ddca991722f32ba2a28 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:23:47 +0200 Subject: [PATCH 05/25] Update 1-js/03-code-quality/02-coding-style/article.md Co-Authored-By: Taras --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index c4d18bd24..2070acb67 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -88,7 +88,7 @@ if (condition) { let str = ` Робоча група TC39 організації ECMA International - це група JavaScript-розробників, спеціалістів з інтеграції, - науковців, і т.д., які працюють разом зі спільнотою + науковців тощо, які працюють разом зі спільнотою над підтримкою та розвитком мови JavaScript. `; ``` From f6ea17d094803632d8865cae5cb4c9d61560996e Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:24:30 +0200 Subject: [PATCH 06/25] Fix minor typos and mistakes --- .../02-coding-style/1-style-errors/solution.md | 2 +- 1-js/03-code-quality/02-coding-style/article.md | 16 ++++++++-------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md index 699a426e1..d4e5ced43 100644 --- a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md +++ b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md @@ -6,7 +6,7 @@ function pow(x,n) // <- немає пробілу між аргументами { // <- фігурна дужка на окремому рядку let result=1; // <- немає пробілу до і після знаку = for(let i=0;i -Давайте розберемо ці правила і причини їх з'явлення більш детально. +Давайте детальніше розглянемо ці правила і причини їх появи. ```warn header="Немає обов'язкових правил" Залізних правил немає. Все це стильові уподобання, а не релігійні догми. @@ -42,7 +42,7 @@ if (n < 0) { ### Фігурні дужки -У більшості JavaScript проектів фігурні дужки написані у так званому "Єгипетському" стилі з відкриваючою дужкою на тому ж рядку, що й відповідне ключове слово -- не на новому рядку. Також потрібно додавати пробіл перед відкриваючою дужкою, наприклад: +У більшості JavaScript проєктів фігурні дужки написані у так званому "Єгипетському" стилі з відкриваючою дужкою на тому ж рядку, що й відповідне ключове слово -- не на новому рядку. Також потрібно додавати пробіл перед відкриваючою дужкою, наприклад: ```js if (condition) { @@ -76,11 +76,11 @@ if (condition) { } ``` -Для дуже короткого коду один рядок є прийнятним, напприклад `if (cond) return null`. Але блок коду (останній варінт) зазвчай є більш читабельним. +Для дуже короткого коду один рядок є прийнятним, наприклад `if (cond) return null`. Але блок коду (останній варінт) зазвичай є більш читабельним. -### Довжина рядку +### Довжина рядка -Ніхто не любить читати довгий горизонтальний рядок коду. Хорошую практикою є розподіляти його на декілька рядків. +Ніхто не любить читати довгий горизонтальний рядок коду. Хорошою практикою є розподіляти його на декілька рядків. Наприклад: ```js @@ -315,7 +315,7 @@ Here are some добре відомих засобів для перевірки 1. Встановіть [Node.js](https://nodejs.org/). 2. Встановіть ESLint, використовуючи команду `npm install -g eslint` (npm – це менеджер JavaScript пакетів (модулів)). -3. Створіть файл конфігурації `.eslintrc` у корні вашого JavaScript проекту (у директорії, що містить всі ваші файли). +3. Створіть файл конфігурації `.eslintrc` у корні вашого JavaScript проєкту (у директорії, що містить всі ваші файли). 4. Встановіть/ввімкніть плагін для вашого редактору, який інтегрується з ESLint. Більшість редакторів мають такий плагін. Ось приклад файлу `.eslintrc`: From 4f4e0cb13f894e2e8afbfcb39fdba05d340d40f7 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:27:41 +0200 Subject: [PATCH 07/25] Fix minor typos and mistakes --- 1-js/03-code-quality/02-coding-style/article.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index a231c5b69..f9509f376 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -87,9 +87,8 @@ if (condition) { // Зворотні апострофи ` дозволяють розподіляти рядок на декілька let str = ` Робоча група TC39 організації ECMA International - - це група JavaScript-розробників, спеціалістів з інтеграції, - науковців тощо, які працюють разом зі спільнотою - над підтримкою та розвитком мови JavaScript. + це група JavaScript-розробників, спеціалістів з інтеграції, науковців тощо, + які працюють разом зі спільнотою над підтримкою та розвитком мови JavaScript. `; ``` @@ -98,14 +97,14 @@ let str = ` ```js if ( id === 123 && - moonPhase === 'Waning Gibbous' && - zodiacSign === 'Libra' + moonPhase === 'Зростаючий місяць' && + zodiacSign === 'Терези' ) { letTheSorceryBegin(); } ``` -Максимальну довжину рядку визначається командою. Зазвичай це `80` або `120` символів. +Максимальну довжину рядка визначається командою. Зазвичай це `80` або `120` символів. ### Відступи From d8bd044c32a10da0045c608952a39654d7583885 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:28:47 +0200 Subject: [PATCH 08/25] Update 1-js/03-code-quality/02-coding-style/article.md Co-Authored-By: Taras --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index f9509f376..0c763a1a6 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -340,7 +340,7 @@ Here are some добре відомих засобів для перевірки Також, деякі середовища розробки (IDE) мають вбудовані засоби первірки коду, що є зручним, але не таким гнучким в налаштуванні рішенням, як ESLint. -## Висновки +## Підсумки Всі правила синтаксису, які описані у даному розділі (і в посиланнях на посібники зі стилю коду) мають на меті поліпшити читабельність вашого коду. Всі вони є дискусійними. From aa0e0cec3948df6b03560011f70f9774864ce385 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:29:29 +0200 Subject: [PATCH 09/25] Update 1-js/03-code-quality/02-coding-style/article.md Co-Authored-By: Taras --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index 0c763a1a6..99a606a52 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -315,7 +315,7 @@ Here are some добре відомих засобів для перевірки 1. Встановіть [Node.js](https://nodejs.org/). 2. Встановіть ESLint, використовуючи команду `npm install -g eslint` (npm – це менеджер JavaScript пакетів (модулів)). 3. Створіть файл конфігурації `.eslintrc` у корні вашого JavaScript проєкту (у директорії, що містить всі ваші файли). -4. Встановіть/ввімкніть плагін для вашого редактору, який інтегрується з ESLint. Більшість редакторів мають такий плагін. +4. Встановіть/увімкніть плаґін для вашого редактора, який інтегрується з ESLint. Більшість редакторів мають такий плаґін. Ось приклад файлу `.eslintrc`: From 74d9c976dd6db323f4ec4af2c4ec79a3486b43fe Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:29:53 +0200 Subject: [PATCH 10/25] Update 1-js/03-code-quality/02-coding-style/article.md Co-Authored-By: Taras --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index 99a606a52..d277529bc 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -116,7 +116,7 @@ if ( Однією з переваг пробілів є те, що пробіли дозволяють більш гнучку конфігурацію відступів, ніж табуляція. - Наприклад, ми можемо вирівняти аругменти відносно відкритої дужки: + Наприклад, ми можемо вирівняти аргументи відносно відкритої дужки: ```js no-beautify show(parameters, From 11aaeb4e19053d6c7a05e985ed952fad67f321d2 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:43:57 +0200 Subject: [PATCH 11/25] Fix mistakes according to the review --- .../02-coding-style/article.md | 42 +++++++++---------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index d277529bc..88bf637b1 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -26,7 +26,7 @@ let n = prompt("n?", ""); if (n < 0) { alert(`Степінь ${n} не підтримується, - please enter a non-negative integer number`); + Будь ласка введіть додатне число`); } else { alert( pow(x, n) ); } @@ -46,9 +46,9 @@ if (n < 0) { ```js if (condition) { - // do this - // ...and that - // ...and that + // зробити це + // ...і це + // ...і це } ``` @@ -58,21 +58,21 @@ if (condition) { 1. 😠 Початківці іноді викорустовують таку конструкцію. Це поганий приклад, фігурні дужки не потрібні: ```js - if (n < 0) *!*{*/!*alert(`Power ${n} is not supported`);*!*}*/!* + if (n < 0) *!*{*/!*alert(`Степінь ${n} не підтримується`);*!*}*/!* ``` 2. 😠 Ніколи не розподіляйте конструкцію на декілька рядків без фігурних дужок - дуже легко зробити помилку при додаванні нового рядка: ```js if (n < 0) - alert(`Power ${n} is not supported`); + alert(`Степінь ${n} не підтримується`); ``` 3. 😏 Писати в один рядок без дужок є прийнятним варіантом, якщо рядок короткий: ```js - if (n < 0) alert(`Power ${n} is not supported`); + if (n < 0) alert(`Степінь ${n} не підтримується`); ``` 4. 😃 Найкращий варіант: ```js if (n < 0) { - alert(`Power ${n} is not supported`); + alert(`Степінь ${n} не підтримується`); } ``` @@ -108,7 +108,7 @@ if ( ### Відступи -Є два види відступів +Є два види відступів: - **Горизонтальні відступи: 2 або 4 пробіли.** @@ -131,7 +131,7 @@ if ( - **Вертикальні відступи: пусті рядки для розподілу коду на "логічні блоки" .** -  Навіть окрема фунція може бути зазвичай розподілена на логічні блоки. У наведенному нижче прикладі, ініціалізація змінних, основний цикл та повернення результату розподілені вертикально: + Навіть окрема фунція може бути розподілена на логічні блоки. У наведенному нижче прикладі, ініціалізація змінних, основний цикл та повернення результату розподілені вертикально: ```js function pow(x, n) { @@ -145,7 +145,7 @@ if ( } ``` - Вставляйте додаткову строку в тому випадку, коли це допомагає зробити код більш зрозумілим. Не повинно бути більше дев'яти строк коду підряд без вертикального розподілу. + Вставляйте додатковий рядок в тому випадку, коли це робить код зрозумілішим. Не повинно бути більше дев'яти рядків коду підряд без вертикального розподілу. ### Крапка з комою @@ -157,9 +157,9 @@ if ( ### Рівні вкладеності -Намагайтесь уникати велику кількість рівнів вкладеності. +Намагайтесь уникати великої кількості рівнів вкладеності. -Наприклад, у циклі, іноді хорошим варіантом є використання директиви [`continue`](info:while-for#continue) для уникнення вкладенності. +Наприклад, у циклі, іноді хорошим варіантом є використання директиви [`continue`](info:while-for#continue) для уникнення вкладеності. Наприклад, замість додавання умови `if`: @@ -221,11 +221,11 @@ function pow(x, n) { } ``` -Друга конструкція є більш зрозумілою, тому що умова `n < 0` обробляється з самого початку. Коли перевірка закінчена ми можемо переходити до "говоного" коду без потреби у додатковому рівні вкладеності. +Друга конструкція є більш зрозумілою, тому що умова `n < 0` обробляється з самого початку. Коли перевірка закінчена ми можемо переходити до "головного" коду без потреби у додатковому рівні вкладеності. -## Розташування Функцій +## Розташування функцій -Якщо ви пишете декілька допоміжних функцій і код, що їх виростуває, є три способи організувати функції. +Якщо ви пишете декілька допоміжних функцій і код, що їх використовує, є три способи організувати функції. 1. Оголосити функції *перед* кодом, що їх використовує: @@ -269,7 +269,7 @@ function pow(x, n) { ... } ``` -3. Зміжаний варінт: функція оголошена там, де вона вперше використовується. +3. Змішаний варіант: функція оголошена там, де вона вперше використовується. Зазвичай, віддають перевагу другому варіанту. @@ -277,11 +277,11 @@ function pow(x, n) { ## Посібники зі Стилю Коду -Посібник зі стилю коду містить загальні правила "як писати" код, наприклад, які лапки використовувати, скількі пробілів ставити для відступу, максимальну довжину рядка, і таке інше. Тобто, багато дрібниць. +Посібник зі стилю коду містить загальні правила "як писати" код, наприклад, які лапки використовувати, скільки пробілів ставити для відступу, максимальну довжину рядка, і таке інше. Тобто, багато дрібниць. Коли всі члени команди використовують посібник зі стилю, код виглядає однаковим, незалежно від того, хто з команди його написав. -Звичайно, кожна команда може завжди створити свій посібник зі стилю, але зазвичай в тому не має потреби. Є багато існуючих посібників серед який можна вибрати. +Звичайно, кожна команда може завжди створити свій посібник зі стилю, але зазвичай в цьому не має потреби. Є багато посібників, серед яких можна вибрати найбільш підходящий. Деякі популярні посібники: @@ -297,7 +297,7 @@ function pow(x, n) { Автоматичні засоби перевірки, так звані "лінтери" - це інструменти, що автоматично перевіряють стиль коду та вносять пропозиції щодо його вдосконалення. -Саме чудове в них є те, зо вони можуть також знайти деякі програмні помилки, наприклад друкарську помилку у назві змінної чи функції. Завдяки цій особливості, рекомендують використовувати лінтер навіть тоді, коли ви не збираєтесь дотримуватись якогось конкретного "стилю коду". +Найкраще в них те, що вони також можуть знайти деякі програмні помилки, наприклад друкарську помилку у назві змінної чи функції. Завдяки цій особливості, рекомендують використовувати лінтер навіть тоді, коли ви не збираєтесь дотримуватись якогось конкретного "стилю коду". Ось декілька Here are some добре відомих засобів для перевірки: @@ -308,7 +308,7 @@ Here are some добре відомих засобів для перевірки Всі вони роблять свою справу. Автор використовує [ESLint](http://eslint.org/). -Більшість лінтерів інтегровані у популярні редактори: просто ввімкнуть відповідний плагін у редакторі і налаштуйте стиль. +Більшість лінтерів інтегровані в популярні редактори: просто увімкніть відповідний плаґін в редакторі і налаштуйте стиль. Наприклад, для ESLint вам потрібно зробити наступне: From 0998cd241739c44c2fc2660d80f390a7e1801233 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:48:11 +0200 Subject: [PATCH 12/25] one more minor correction --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index 88bf637b1..d7917c85f 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -314,7 +314,7 @@ Here are some добре відомих засобів для перевірки 1. Встановіть [Node.js](https://nodejs.org/). 2. Встановіть ESLint, використовуючи команду `npm install -g eslint` (npm – це менеджер JavaScript пакетів (модулів)). -3. Створіть файл конфігурації `.eslintrc` у корні вашого JavaScript проєкту (у директорії, що містить всі ваші файли). +3. Створіть файл конфігурації `.eslintrc` в корні вашого JavaScript проєкту (у директорії, що містить всі ваші файли). 4. Встановіть/увімкніть плаґін для вашого редактора, який інтегрується з ESLint. Більшість редакторів мають такий плаґін. Ось приклад файлу `.eslintrc`: From ee977f1309470c8d04cde236bbfcd68db661e7e0 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Wed, 26 Feb 2020 03:37:23 +0200 Subject: [PATCH 13/25] Translate Code Style section --- .../1-style-errors/solution.md | 27 +-- .../02-coding-style/1-style-errors/task.md | 6 +- .../02-coding-style/article.md | 190 +++++++++--------- .../02-coding-style/code-style.svg | 2 +- 4 files changed, 114 insertions(+), 111 deletions(-) diff --git a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md index 764e36c63..9945e7807 100644 --- a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md +++ b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md @@ -1,29 +1,30 @@ +Ви можете You could note the following: ```js no-beautify -function pow(x,n) // <- no space between arguments -{ // <- figure bracket on a separate line - let result=1; // <- no spaces before or after = - for(let i=0;i -Now let's discuss the rules and reasons for them in detail. +Давайте розберемо ці правила і причини їх з'явлення більш детально. -```warn header="There are no \"you must\" rules" -Nothing is set in stone here. These are style preferences, not religious dogmas. +```warn header="Немає обов'язкових правил" +Залізних правил немає. Все це стильові уподобання, а не релігійні догми. ``` -### Curly Braces +### Фігурні дужки -In most JavaScript projects curly braces are written in "Egyptian" style with the opening brace on the same line as the corresponding keyword -- not on a new line. There should also be a space before the opening bracket, like this: +У більшості JavaScript проектів фігурні дужки написані у так званому "Єгипетському" стилі з відкриваючою дужкою на тому ж рядку, що й відповідне ключове слово -- не на новому рядку. Також потрібно додавати пробіл перед відкриваючою дужкою, наприклад: ```js if (condition) { @@ -52,47 +52,48 @@ if (condition) { } ``` -A single-line construct, such as `if (condition) doSomething()`, is an important edge case. Should we use braces at all? +Чи потрібно ставити дужки, коли конструкція складається з одного рядка, наприклад `if (condition) doSomething()`? -Here are the annotated variants so you can judge their readability for yourself: +Нижче наведені різні варіанти розташування дужок з коментарями, щоб ви змогли самостійно вирішити який варіант є найбільш читабельним. -1. 😠 Beginners sometimes do that. Bad! Curly braces are not needed: +1. 😠 Початківці іноді викорустовують таку конструкцію. Це поганий приклад, фігурні дужки не потрібні: ```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. 😠 Ніколи не розподіляйте конструкцію на декілька рядків без фігурних дужок - дуже легко зробити помилку при додаванні нового рядка: ```js if (n < 0) alert(`Power ${n} is not supported`); ``` -3. 😏 One line without braces - acceptable, if it's short: +3. 😏 Писати в один рядок без дужок є прийнятним варіантом, якщо рядок короткий: ```js if (n < 0) alert(`Power ${n} is not supported`); ``` -4. 😃 The best variant: +4. 😃 Найкращий варіант: ```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. +Для дуже короткого коду один рядок є прийнятним, напприклад `if (cond) return null`. Але блок коду (останній варінт) зазвчай є більш читабельним. -### Line Length +### Довжина рядку -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. + Робоча група TC39 організації ECMA International - + це група JavaScript-розробників, спеціалістів з інтеграції, + науковців, і т.д., які працюють разом зі спільнотою + над підтримкою та розвитком мови JavaScript. `; ``` -And, for `if` statements: +Або для `if`: ```js if ( @@ -104,23 +105,23 @@ if ( } ``` -The maximum line length should be agreed upon at the team-level. It's usually 80 or 120 characters. +Максимальну довжину рядку визначається командою. Зазвичай це `80` або `120` символів. -### Indents +### Відступи -There are two types of indents: +Є два види відступів -- **Horizontal indents: 2 or 4 spaces.** +- **Горизонтальні відступи: 2 або 4 пробіли.** - A horizontal indentation is made using either 2 or 4 spaces or the horizontal tab symbol (key `key:Tab`). Which one to choose is an old holy war. Spaces are more common nowadays. + Горизонтальний відступ робиться за допогою двох або чотирьох пробілів, або за допомогою табуляції (клавіша `key:Tab`). Який відступ вибирати - вирішувати вам. Відступ з пробілам більш поширений на сьогодні. - One advantage of spaces over tabs is that spaces allow more flexible configurations of indents than the tab symbol. + Однією з переваг пробілів є те, що пробіли дозволяють більш гнучку конфігурацію відступів, ніж табуляція. - For instance, we can align the arguments with the opening bracket, like this: + Наприклад, ми можемо вирівняти аругменти відносно відкритої дужки: ```js no-beautify show(parameters, - aligned, // 5 spaces padding at the left + aligned, // 5 пробілів зліва one, after, another @@ -129,9 +130,9 @@ There are two types of indents: } ``` -- **Vertical indents: empty lines for splitting code into logical blocks.** +- **Вертикальні відступи: пусті рядки для розподілу коду на "логічні блоки" .** - Even a single function can often be divided into logical blocks. In the example below, the initialization of variables, the main loop and returning the result are split vertically: +  Навіть окрема фунція може бути зазвичай розподілена на логічні блоки. У наведенному нижче прикладі, ініціалізація змінних, основний цикл та повернення результату розподілені вертикально: ```js function pow(x, n) { @@ -145,51 +146,51 @@ There are two types of indents: } ``` - Insert an extra newline where it helps to make the code more readable. There should not be more than nine lines of code without a vertical indentation. + Вставляйте додаткову строку в тому випадку, коли це допомагає зробити код більш зрозумілим. Не повинно бути більше дев'яти строк коду підряд без вертикального розподілу. -### Semicolons +### Крапка з комою -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. See more about that in the chapter . +Є мови програмування, у яких крапка з комою є дійсно необов'язковими і рідко використовуються. Проте у JavaScript є ситуації коли перенос строки не інтерпретується як крапка з комою, залишаючи код вразливим до помилок. Більше детально про це знайдете у розділі . -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. +Якщо ви досвідчений JavaScript програміст, ви можете обрати стиль коду без крапки з комою, наприклад [StandardJS](https://standardjs.com/). Інакше, краще використовувати крапку з комою для того, щоб уникнути підводних каменів. Більшість розробників використовують крапку з комою. -### Nesting Levels +### Рівні вкладеності -Try to avoid nesting code too many levels deep. +Намагайтесь уникати велику кількість рівнів вкладеності. -For example, in the loop, it's sometimes a good idea to use the [`continue`](info:while-for#continue) directive to avoid extra nesting. +Наприклад, у циклі, іноді хорошим варіантом є використання директиви [`continue`](info:while-for#continue) для уникнення вкладенності. -For example, instead of adding a nested `if` conditional like this: +Наприклад, замість додавання умови `if`: ```js for (let i = 0; i < 10; i++) { if (cond) { - ... // <- one more nesting level + ... // <- ще один рівень вкладеності } } ``` -We can write: +ми можемо написати: ```js for (let i = 0; i < 10; i++) { if (!cond) *!*continue*/!*; - ... // <- no extra nesting level + ... // <- немає вкладеності } ``` -A similar thing can be done with `if/else` and `return`. +Схожим чином ми можемо змінити `if/else` та `return`. -For example, two constructs below are identical. +Наприклад, дві конструкції нижче є ідентичними. -Option 1: +Перша: ```js function pow(x, n) { if (n < 0) { - alert("Negative 'n' not supported"); + alert("Від'ємні значення 'n' не підтримуються"); } else { let result = 1; @@ -202,12 +203,12 @@ function pow(x, n) { } ``` -Option 2: +Друга: ```js function pow(x, n) { if (n < 0) { - alert("Negative 'n' not supported"); + alert("Від'ємні значення 'n' не підтримуються"); return; } @@ -221,16 +222,16 @@ function pow(x, n) { } ``` -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. +Друга конструкція є більш зрозумілою, тому що умова `n < 0` обробляється з самого початку. Коли перевірка закінчена ми можемо переходити до "говоного" коду без потреби у додатковому рівні вкладеності. -## Function Placement +## Розташування Функцій -If you are writing several "helper" functions and the code that uses them, there are three ways to organize the functions. +Якщо ви пишете декілька допоміжних функцій і код, що їх виростуває, є три способи організувати функції. -1. Declare the functions *above* the code that uses them: +1. Оголосити функції *перед* кодом, що їх використовує: ```js - // *!*function declarations*/!* + // *!*оголошення функій*/!* function createElement() { ... } @@ -243,20 +244,20 @@ If you are writing several "helper" functions and the code that uses them, there ... } - // *!*the code which uses them*/!* + // *!*код, що їх використовує*/!* let elem = createElement(); setHandler(elem); walkAround(); ``` -2. Code first, then functions +2. Спочатку код, потім функції ```js - // *!*the code which uses the functions*/!* + // *!*код, що використовує функції*/!* let elem = createElement(); setHandler(elem); walkAround(); - // --- *!*helper functions*/!* --- + // --- *!*допоміжні функції*/!* --- function createElement() { ... } @@ -269,54 +270,55 @@ If you are writing several "helper" functions and the code that uses them, there ... } ``` -3. Mixed: a function is declared where it's first used. +3. Зміжаний варінт: функція оголошена там, де вона вперше використовується. -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 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, the maximal line length, 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, but usually there's no need to. There are many existing guides to choose from. +Звичайно, кожна команда може завжди створити свій посібник зі стилю, але зазвичай в тому не має потреби. Є багато існуючих посібників серед який можна вибрати. -Some popular choices: +Деякі популярні посібники: - [Google JavaScript Style Guide](https://google.github.io/styleguide/javascriptguide.xml) - [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) - [Idiomatic.JS](https://github.com/rwaldron/idiomatic.js) - [StandardJS](https://standardjs.com/) -- (plus many more) +- (і ще багато інших) -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 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, using a linter is recommended even if you don't want to stick to one particular "code style". +Саме чудове в них є те, зо вони можуть також знайти деякі програмні помилки, наприклад друкарську помилку у назві змінної чи функції. Завдяки цій особливості, рекомендують використовувати лінтер навіть тоді, коли ви не збираєтесь дотримуватись якогось конкретного "стилю коду". -Here are some well-known linting tools: +Ось декілька +Here are some добре відомих засобів для перевірки: -- [JSLint](http://www.jslint.com/) -- one of the first linters. -- [JSHint](http://www.jshint.com/) -- more settings than JSLint. -- [ESLint](http://eslint.org/) -- probably the newest one. +- [JSLint](http://www.jslint.com/) -- один з перших лінтерів. +- [JSHint](http://www.jshint.com/) -- має більше налаштувань ніж JSLint. +- [ESLint](http://eslint.org/) -- напевно, найсучасніший лінтер. -All of them can do the job. The author uses [ESLint](http://eslint.org/). +Всі вони роблять свою справу. Автор використовує [ESLint](http://eslint.org/). -Most linters are integrated with many popular editors: just enable the plugin in the editor and configure the style. +Більшість лінтерів інтегровані у популярні редактори: просто ввімкнуть відповідний плагін у редакторі і налаштуйте стиль. -For instance, for ESLint you should do the following: +Наприклад, для ESLint вам потрібно зробити наступне: -1. Install [Node.js](https://nodejs.org/). -2. Install ESLint with the command `npm install -g eslint` (npm is a JavaScript package installer). -3. Create a config file named `.eslintrc` in the root of your JavaScript project (in the folder that contains all your files). -4. Install/enable the plugin for your editor that integrates with ESLint. The majority of editors have one. +1. Встановіть [Node.js](https://nodejs.org/). +2. Встановіть ESLint використовуючи команду `npm install -g eslint` (npm це менеджер JavaScript пакетів(модулів)). +3. Створіть файл конфігурації `.eslintrc` у корні вашого JavaScript проекту (у директорії, що містить всі ваші файли). +4. Встановіть/ввімкніть плагін для вашого редактору, який інтегрується з ESLint. Більшість редакторів мають такий плагін. -Here's an example of an `.eslintrc` file: +Ось приклад файлу `.eslintrc`: ```js { @@ -333,16 +335,16 @@ Here's an example of an `.eslintrc` file: } ``` -Here the directive `"extends"` denotes that the configuration is based on the "eslint:recommended" set of settings. After that, we specify our own. +Директива `"extends"` означає, що конфігурація базується на наборі налаштувань "eslint:recommended". Після цього, ви вказуєте ваші власні. -It is also possible to download style rule sets from the web and extend them instead. See for more details about installation. +Крім того, можна завантажити набори правил з мережі та розширити їх. Дивіться для отримання більш детальної інструкції зі встановлення. -Also certain IDEs have built-in linting, which is convenient but not as customizable as ESLint. +Також, деякі середовища розробки (IDE) мають вбудовані засоби первірки коду, що є зручним, але не таким гнучким в налаштуванні рішенням, як ESLint. -## Summary +## Висновки -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 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. +Читання популярних посібників зі стилю коду дозволить вам бути в курсі найкращих практик та останніх ідей щодо стилю коду. diff --git a/1-js/03-code-quality/02-coding-style/code-style.svg b/1-js/03-code-quality/02-coding-style/code-style.svg index bd62691c6..79626a4bd 100644 --- a/1-js/03-code-quality/02-coding-style/code-style.svg +++ b/1-js/03-code-quality/02-coding-style/code-style.svg @@ -1 +1 @@ -2No space between the function name and parentheses between the parentheses and the parameterIndentation 2 spacesA space after for/if/while…} else { without a line breakSpaces around a nested callAn empty line between logical blocksLines are not very longA semicolon ; is mandatorySpaces around operatorsCurly brace { on the same line, after a spaceA space between parametersA space between parameters \ No newline at end of file +2Немає пробілу між ім'ям функції і круглими дужками та між круглими дужками та параметромВідступ 2 пробіли Пробіл після for/if/while…} else { на одному рядкуПробіли навколо вкладеного викликуПустий рядок між логічними блокамиРядки короткіКрапка з комою ; є обов'язковоюПробіли навколо операторівФігурна дужка { на тому ж рядку, після пробілуПробіл між параметрами Пробіл між параметрами \ No newline at end of file From f3b11a34eba029260e35b3c5ffac1fb74e926494 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Wed, 26 Feb 2020 03:44:13 +0200 Subject: [PATCH 14/25] Fixed mistake in solution translation --- .../03-code-quality/02-coding-style/1-style-errors/solution.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md index 9945e7807..699a426e1 100644 --- a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md +++ b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md @@ -1,6 +1,5 @@ -Ви можете -You could note the following: +Ви можете зробити наступні відмітки: ```js no-beautify function pow(x,n) // <- немає пробілу між аргументами From cbcfd031a3f1f3f0975fffd6f1677339d363eed9 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:14:33 +0200 Subject: [PATCH 15/25] Update 1-js/03-code-quality/02-coding-style/article.md Co-Authored-By: Taras --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index 0425625f4..2aaef14ae 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -314,7 +314,7 @@ Here are some добре відомих засобів для перевірки Наприклад, для ESLint вам потрібно зробити наступне: 1. Встановіть [Node.js](https://nodejs.org/). -2. Встановіть ESLint використовуючи команду `npm install -g eslint` (npm це менеджер JavaScript пакетів(модулів)). +2. Встановіть ESLint, використовуючи команду `npm install -g eslint` (npm – це менеджер JavaScript пакетів (модулів)). 3. Створіть файл конфігурації `.eslintrc` у корні вашого JavaScript проекту (у директорії, що містить всі ваші файли). 4. Встановіть/ввімкніть плагін для вашого редактору, який інтегрується з ESLint. Більшість редакторів мають такий плагін. From edc13e64b4399d50a26d3ee372248cd4f8468239 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:14:48 +0200 Subject: [PATCH 16/25] Update 1-js/03-code-quality/02-coding-style/article.md Co-Authored-By: Taras --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index 2aaef14ae..c4d18bd24 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -339,7 +339,7 @@ Here are some добре відомих засобів для перевірки Крім того, можна завантажити набори правил з мережі та розширити їх. Дивіться для отримання більш детальної інструкції зі встановлення. -Також, деякі середовища розробки (IDE) мають вбудовані засоби первірки коду, що є зручним, але не таким гнучким в налаштуванні рішенням, як ESLint. +Також, деякі середовища розробки (IDE) мають вбудовані засоби первірки коду, що є зручним, але не таким гнучким в налаштуванні рішенням, як ESLint. ## Висновки From f2c65f605006f22523caf40dd5b66c3ad47e9bee Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:24:30 +0200 Subject: [PATCH 17/25] Fix minor typos and mistakes --- .../02-coding-style/1-style-errors/solution.md | 2 +- 1-js/03-code-quality/02-coding-style/article.md | 16 ++++++++-------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md index 699a426e1..d4e5ced43 100644 --- a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md +++ b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md @@ -6,7 +6,7 @@ function pow(x,n) // <- немає пробілу між аргументами { // <- фігурна дужка на окремому рядку let result=1; // <- немає пробілу до і після знаку = for(let i=0;i -Давайте розберемо ці правила і причини їх з'явлення більш детально. +Давайте детальніше розглянемо ці правила і причини їх появи. ```warn header="Немає обов'язкових правил" Залізних правил немає. Все це стильові уподобання, а не релігійні догми. @@ -42,7 +42,7 @@ if (n < 0) { ### Фігурні дужки -У більшості JavaScript проектів фігурні дужки написані у так званому "Єгипетському" стилі з відкриваючою дужкою на тому ж рядку, що й відповідне ключове слово -- не на новому рядку. Також потрібно додавати пробіл перед відкриваючою дужкою, наприклад: +У більшості JavaScript проєктів фігурні дужки написані у так званому "Єгипетському" стилі з відкриваючою дужкою на тому ж рядку, що й відповідне ключове слово -- не на новому рядку. Також потрібно додавати пробіл перед відкриваючою дужкою, наприклад: ```js if (condition) { @@ -76,11 +76,11 @@ if (condition) { } ``` -Для дуже короткого коду один рядок є прийнятним, напприклад `if (cond) return null`. Але блок коду (останній варінт) зазвчай є більш читабельним. +Для дуже короткого коду один рядок є прийнятним, наприклад `if (cond) return null`. Але блок коду (останній варінт) зазвичай є більш читабельним. -### Довжина рядку +### Довжина рядка -Ніхто не любить читати довгий горизонтальний рядок коду. Хорошую практикою є розподіляти його на декілька рядків. +Ніхто не любить читати довгий горизонтальний рядок коду. Хорошою практикою є розподіляти його на декілька рядків. Наприклад: ```js @@ -315,7 +315,7 @@ Here are some добре відомих засобів для перевірки 1. Встановіть [Node.js](https://nodejs.org/). 2. Встановіть ESLint, використовуючи команду `npm install -g eslint` (npm – це менеджер JavaScript пакетів (модулів)). -3. Створіть файл конфігурації `.eslintrc` у корні вашого JavaScript проекту (у директорії, що містить всі ваші файли). +3. Створіть файл конфігурації `.eslintrc` у корні вашого JavaScript проєкту (у директорії, що містить всі ваші файли). 4. Встановіть/ввімкніть плагін для вашого редактору, який інтегрується з ESLint. Більшість редакторів мають такий плагін. Ось приклад файлу `.eslintrc`: From 9684e5d64d4561ccd7f23f20704c6133a8890ec1 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:23:47 +0200 Subject: [PATCH 18/25] Update 1-js/03-code-quality/02-coding-style/article.md Co-Authored-By: Taras --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index 47bb82309..a231c5b69 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -88,7 +88,7 @@ if (condition) { let str = ` Робоча група TC39 організації ECMA International - це група JavaScript-розробників, спеціалістів з інтеграції, - науковців, і т.д., які працюють разом зі спільнотою + науковців тощо, які працюють разом зі спільнотою над підтримкою та розвитком мови JavaScript. `; ``` From 0ba48b62fc951adf07283f784856fce233b6d1a2 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:27:41 +0200 Subject: [PATCH 19/25] Fix minor typos and mistakes --- 1-js/03-code-quality/02-coding-style/article.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index a231c5b69..f9509f376 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -87,9 +87,8 @@ if (condition) { // Зворотні апострофи ` дозволяють розподіляти рядок на декілька let str = ` Робоча група TC39 організації ECMA International - - це група JavaScript-розробників, спеціалістів з інтеграції, - науковців тощо, які працюють разом зі спільнотою - над підтримкою та розвитком мови JavaScript. + це група JavaScript-розробників, спеціалістів з інтеграції, науковців тощо, + які працюють разом зі спільнотою над підтримкою та розвитком мови JavaScript. `; ``` @@ -98,14 +97,14 @@ let str = ` ```js if ( id === 123 && - moonPhase === 'Waning Gibbous' && - zodiacSign === 'Libra' + moonPhase === 'Зростаючий місяць' && + zodiacSign === 'Терези' ) { letTheSorceryBegin(); } ``` -Максимальну довжину рядку визначається командою. Зазвичай це `80` або `120` символів. +Максимальну довжину рядка визначається командою. Зазвичай це `80` або `120` символів. ### Відступи From d4269aaba7c75735a8cdd189cdae79ed974e597c Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:28:47 +0200 Subject: [PATCH 20/25] Update 1-js/03-code-quality/02-coding-style/article.md Co-Authored-By: Taras --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index f9509f376..0c763a1a6 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -340,7 +340,7 @@ Here are some добре відомих засобів для перевірки Також, деякі середовища розробки (IDE) мають вбудовані засоби первірки коду, що є зручним, але не таким гнучким в налаштуванні рішенням, як ESLint. -## Висновки +## Підсумки Всі правила синтаксису, які описані у даному розділі (і в посиланнях на посібники зі стилю коду) мають на меті поліпшити читабельність вашого коду. Всі вони є дискусійними. From 33bf37fe172455023af1c7d36871a982cadb2742 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:29:29 +0200 Subject: [PATCH 21/25] Update 1-js/03-code-quality/02-coding-style/article.md Co-Authored-By: Taras --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index 0c763a1a6..99a606a52 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -315,7 +315,7 @@ Here are some добре відомих засобів для перевірки 1. Встановіть [Node.js](https://nodejs.org/). 2. Встановіть ESLint, використовуючи команду `npm install -g eslint` (npm – це менеджер JavaScript пакетів (модулів)). 3. Створіть файл конфігурації `.eslintrc` у корні вашого JavaScript проєкту (у директорії, що містить всі ваші файли). -4. Встановіть/ввімкніть плагін для вашого редактору, який інтегрується з ESLint. Більшість редакторів мають такий плагін. +4. Встановіть/увімкніть плаґін для вашого редактора, який інтегрується з ESLint. Більшість редакторів мають такий плаґін. Ось приклад файлу `.eslintrc`: From 80963245f8f91af0eed20fc1015cace6794e8d4a Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:29:53 +0200 Subject: [PATCH 22/25] Update 1-js/03-code-quality/02-coding-style/article.md Co-Authored-By: Taras --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index 99a606a52..d277529bc 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -116,7 +116,7 @@ if ( Однією з переваг пробілів є те, що пробіли дозволяють більш гнучку конфігурацію відступів, ніж табуляція. - Наприклад, ми можемо вирівняти аругменти відносно відкритої дужки: + Наприклад, ми можемо вирівняти аргументи відносно відкритої дужки: ```js no-beautify show(parameters, From 5b3d4c06d102b55a8b2f988ab4db8534462edd28 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:43:57 +0200 Subject: [PATCH 23/25] Fix mistakes according to the review --- .../02-coding-style/article.md | 42 +++++++++---------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index d277529bc..88bf637b1 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -26,7 +26,7 @@ let n = prompt("n?", ""); if (n < 0) { alert(`Степінь ${n} не підтримується, - please enter a non-negative integer number`); + Будь ласка введіть додатне число`); } else { alert( pow(x, n) ); } @@ -46,9 +46,9 @@ if (n < 0) { ```js if (condition) { - // do this - // ...and that - // ...and that + // зробити це + // ...і це + // ...і це } ``` @@ -58,21 +58,21 @@ if (condition) { 1. 😠 Початківці іноді викорустовують таку конструкцію. Це поганий приклад, фігурні дужки не потрібні: ```js - if (n < 0) *!*{*/!*alert(`Power ${n} is not supported`);*!*}*/!* + if (n < 0) *!*{*/!*alert(`Степінь ${n} не підтримується`);*!*}*/!* ``` 2. 😠 Ніколи не розподіляйте конструкцію на декілька рядків без фігурних дужок - дуже легко зробити помилку при додаванні нового рядка: ```js if (n < 0) - alert(`Power ${n} is not supported`); + alert(`Степінь ${n} не підтримується`); ``` 3. 😏 Писати в один рядок без дужок є прийнятним варіантом, якщо рядок короткий: ```js - if (n < 0) alert(`Power ${n} is not supported`); + if (n < 0) alert(`Степінь ${n} не підтримується`); ``` 4. 😃 Найкращий варіант: ```js if (n < 0) { - alert(`Power ${n} is not supported`); + alert(`Степінь ${n} не підтримується`); } ``` @@ -108,7 +108,7 @@ if ( ### Відступи -Є два види відступів +Є два види відступів: - **Горизонтальні відступи: 2 або 4 пробіли.** @@ -131,7 +131,7 @@ if ( - **Вертикальні відступи: пусті рядки для розподілу коду на "логічні блоки" .** -  Навіть окрема фунція може бути зазвичай розподілена на логічні блоки. У наведенному нижче прикладі, ініціалізація змінних, основний цикл та повернення результату розподілені вертикально: + Навіть окрема фунція може бути розподілена на логічні блоки. У наведенному нижче прикладі, ініціалізація змінних, основний цикл та повернення результату розподілені вертикально: ```js function pow(x, n) { @@ -145,7 +145,7 @@ if ( } ``` - Вставляйте додаткову строку в тому випадку, коли це допомагає зробити код більш зрозумілим. Не повинно бути більше дев'яти строк коду підряд без вертикального розподілу. + Вставляйте додатковий рядок в тому випадку, коли це робить код зрозумілішим. Не повинно бути більше дев'яти рядків коду підряд без вертикального розподілу. ### Крапка з комою @@ -157,9 +157,9 @@ if ( ### Рівні вкладеності -Намагайтесь уникати велику кількість рівнів вкладеності. +Намагайтесь уникати великої кількості рівнів вкладеності. -Наприклад, у циклі, іноді хорошим варіантом є використання директиви [`continue`](info:while-for#continue) для уникнення вкладенності. +Наприклад, у циклі, іноді хорошим варіантом є використання директиви [`continue`](info:while-for#continue) для уникнення вкладеності. Наприклад, замість додавання умови `if`: @@ -221,11 +221,11 @@ function pow(x, n) { } ``` -Друга конструкція є більш зрозумілою, тому що умова `n < 0` обробляється з самого початку. Коли перевірка закінчена ми можемо переходити до "говоного" коду без потреби у додатковому рівні вкладеності. +Друга конструкція є більш зрозумілою, тому що умова `n < 0` обробляється з самого початку. Коли перевірка закінчена ми можемо переходити до "головного" коду без потреби у додатковому рівні вкладеності. -## Розташування Функцій +## Розташування функцій -Якщо ви пишете декілька допоміжних функцій і код, що їх виростуває, є три способи організувати функції. +Якщо ви пишете декілька допоміжних функцій і код, що їх використовує, є три способи організувати функції. 1. Оголосити функції *перед* кодом, що їх використовує: @@ -269,7 +269,7 @@ function pow(x, n) { ... } ``` -3. Зміжаний варінт: функція оголошена там, де вона вперше використовується. +3. Змішаний варіант: функція оголошена там, де вона вперше використовується. Зазвичай, віддають перевагу другому варіанту. @@ -277,11 +277,11 @@ function pow(x, n) { ## Посібники зі Стилю Коду -Посібник зі стилю коду містить загальні правила "як писати" код, наприклад, які лапки використовувати, скількі пробілів ставити для відступу, максимальну довжину рядка, і таке інше. Тобто, багато дрібниць. +Посібник зі стилю коду містить загальні правила "як писати" код, наприклад, які лапки використовувати, скільки пробілів ставити для відступу, максимальну довжину рядка, і таке інше. Тобто, багато дрібниць. Коли всі члени команди використовують посібник зі стилю, код виглядає однаковим, незалежно від того, хто з команди його написав. -Звичайно, кожна команда може завжди створити свій посібник зі стилю, але зазвичай в тому не має потреби. Є багато існуючих посібників серед який можна вибрати. +Звичайно, кожна команда може завжди створити свій посібник зі стилю, але зазвичай в цьому не має потреби. Є багато посібників, серед яких можна вибрати найбільш підходящий. Деякі популярні посібники: @@ -297,7 +297,7 @@ function pow(x, n) { Автоматичні засоби перевірки, так звані "лінтери" - це інструменти, що автоматично перевіряють стиль коду та вносять пропозиції щодо його вдосконалення. -Саме чудове в них є те, зо вони можуть також знайти деякі програмні помилки, наприклад друкарську помилку у назві змінної чи функції. Завдяки цій особливості, рекомендують використовувати лінтер навіть тоді, коли ви не збираєтесь дотримуватись якогось конкретного "стилю коду". +Найкраще в них те, що вони також можуть знайти деякі програмні помилки, наприклад друкарську помилку у назві змінної чи функції. Завдяки цій особливості, рекомендують використовувати лінтер навіть тоді, коли ви не збираєтесь дотримуватись якогось конкретного "стилю коду". Ось декілька Here are some добре відомих засобів для перевірки: @@ -308,7 +308,7 @@ Here are some добре відомих засобів для перевірки Всі вони роблять свою справу. Автор використовує [ESLint](http://eslint.org/). -Більшість лінтерів інтегровані у популярні редактори: просто ввімкнуть відповідний плагін у редакторі і налаштуйте стиль. +Більшість лінтерів інтегровані в популярні редактори: просто увімкніть відповідний плаґін в редакторі і налаштуйте стиль. Наприклад, для ESLint вам потрібно зробити наступне: From 47883104c39b9e180baff6f5b00acb21af3019a8 Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 00:48:11 +0200 Subject: [PATCH 24/25] one more minor correction --- 1-js/03-code-quality/02-coding-style/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index 88bf637b1..d7917c85f 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -314,7 +314,7 @@ Here are some добре відомих засобів для перевірки 1. Встановіть [Node.js](https://nodejs.org/). 2. Встановіть ESLint, використовуючи команду `npm install -g eslint` (npm – це менеджер JavaScript пакетів (модулів)). -3. Створіть файл конфігурації `.eslintrc` у корні вашого JavaScript проєкту (у директорії, що містить всі ваші файли). +3. Створіть файл конфігурації `.eslintrc` в корні вашого JavaScript проєкту (у директорії, що містить всі ваші файли). 4. Встановіть/увімкніть плаґін для вашого редактора, який інтегрується з ESLint. Більшість редакторів мають такий плаґін. Ось приклад файлу `.eslintrc`: From cdd5a3a8b93af3e6a822f81c7d3c579ee012ce8e Mon Sep 17 00:00:00 2001 From: Alex Galkin Date: Thu, 27 Feb 2020 20:36:31 +0200 Subject: [PATCH 25/25] minor fix --- 1-js/03-code-quality/02-coding-style/article.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index d7917c85f..bc01a24a2 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -299,8 +299,7 @@ function pow(x, n) { Найкраще в них те, що вони також можуть знайти деякі програмні помилки, наприклад друкарську помилку у назві змінної чи функції. Завдяки цій особливості, рекомендують використовувати лінтер навіть тоді, коли ви не збираєтесь дотримуватись якогось конкретного "стилю коду". -Ось декілька -Here are some добре відомих засобів для перевірки: +Ось декілька добре відомих засобів для перевірки: - [JSLint](http://www.jslint.com/) -- один з перших лінтерів. - [JSHint](http://www.jshint.com/) -- має більше налаштувань ніж JSLint.