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..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 @@ -1,29 +1,29 @@ -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) { - // do this - // ...and that - // ...and that + // зробити це + // ...і це + // ...і це } ``` -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`);*!*}*/!* + if (n < 0) *!*{*/!*alert(`Степінь ${n} не підтримується`);*!*}*/!* ``` -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`); + alert(`Степінь ${n} не підтримується`); ``` -3. 😏 One line without braces - acceptable, if it's short: +3. 😏 Писати в один рядок без дужок є прийнятним варіантом, якщо рядок короткий: ```js - if (n < 0) alert(`Power ${n} is not supported`); + if (n < 0) alert(`Степінь ${n} не підтримується`); ``` -4. 😃 The best variant: +4. 😃 Найкращий варіант: ```js if (n < 0) { - alert(`Power ${n} is not supported`); + alert(`Степінь ${n} не підтримується`); } ``` -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 ( id === 123 && - moonPhase === 'Waning Gibbous' && - zodiacSign === 'Libra' + moonPhase === 'Зростаючий місяць' && + zodiacSign === 'Терези' ) { letTheSorceryBegin(); } ``` -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 +129,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 +145,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 +202,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 +221,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 +243,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 +269,54 @@ 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: +Ось декілька добре відомих засобів для перевірки: -- [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 +333,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