From 983c552076d5cdf76f9b6833fecc0cc7fc925060 Mon Sep 17 00:00:00 2001 From: Evgeny Shupikov <41766783+EvgenyShupikov@users.noreply.github.com> Date: Tue, 11 Feb 2020 16:29:17 +0400 Subject: [PATCH] Fixed typos --- README.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/README.md b/README.md index de94011..32374ae 100644 --- a/README.md +++ b/README.md @@ -42,7 +42,7 @@ you shout when reading code](https://www.osnews.com/images/comics/wtfm.jpg) И еще одна вещь: знание этих принципов не делает вас сразу лучшим разработчиком ПО, а их использование в течение многих лет не гарантирует, что вы не будете совершать ошибки. Каждый кусок кода начинается как -черновик, как мокрый кусок глины который только постеменно приобретает свою форму. Не упрекайте себя при +черновик, как мокрый кусок глины который только постепенно приобретает свою форму. Не упрекайте себя при первых набросках кода, которые нуждаются в улучшении. Улучшайте код вместо этого! **[⬆ Вернуться в начало](#содержание)** @@ -246,9 +246,9 @@ function loadPages(count: number = 10) { **[⬆ Вернуться в начало](#содержание)** -### Используйте enum дл документирования +### Используйте enum для документирования -Enam'ы могут помочь документированию вашего кода. Например когда мы обеспокоены тем, что наши переменные +Enum'ы могут помочь документированию вашего кода. Например когда мы обеспокоены тем, что наши переменные отличаются от значений. **Плохо:** @@ -303,12 +303,12 @@ class Projector { ### Аргументы функции (идеально два или меньше) -Ограничение колличества парамметров функции невероятно важно, потому что это делает тестирование ваших +Ограничение колличества параметров функции невероятно важно, потому что это делает тестирование ваших функций проще. Наличие более 3-х аргументов приводит к комбинаторному взрыву, где вы должны протестировать множество вариантов с каждым отдельным аргументом Один или два аргумента это идеальный случай, а три и более следует избегать, если это возможно. -Большое колличество аргументов лучше объеденять. Обычно если вы используете более двух аргументов, то ваша функция пытается +Большое колличество аргументов лучше объединять. Обычно если вы используете более двух аргументов, то ваша функция пытается делать слишком много. В случаях когда это не так, то лучше использовать объект верхнего уровня. Подумайте о том чтобы использовать объектные литералы, если вам необходимо много аргументов. @@ -323,7 +323,7 @@ class Projector { 2. Деструктуризация также клонирует примитивные значения аргумента-объекта переданного в функцию. Это помогает избежать сайд эффекта. Заметка: объекты и массивы которые деструктурированы из аргумента-объекта не клонируются. -3. TypeScript предупреждает о неиспользуемых свойствах, это было бы не возможно без деструктуризации. +3. TypeScript предупреждает о неиспользуемых свойствах, это было бы невозможно без деструктуризации. **Плохо:** @@ -373,9 +373,9 @@ createMenu({ ### Функции должны выполнять одну задачу Это одно из самых важных правил в разработке ПО. Когда функции решают больше одной задачи, -их труднее объеденять, тестировать. Если вы сможете изолировать функцию так чтобы она выполняла только одну задачу, +их труднее объединять, тестировать. Если вы сможете изолировать функцию так чтобы она выполняла только одну задачу, в дальнейшем она может быть легко переработана, а ваш код будет чище. Если вы запомните только это правило из этого - руководства, то вы уже будете лучще многих разработчиков. + руководства, то вы уже будете лучше многих разработчиков. **Плохо:** @@ -435,7 +435,7 @@ addMonthToDate(date, 1); ### Функции должны иметь один уровень абстракции -Если у вас больще одного уровня абстракции, то обычно эта функция делает слишком мноое. Разделение функций дает возможность +Если у вас больше одного уровня абстракции, то обычно эта функция делает слишком многое. Разделение функций дает возможность переиспользования и простого тестирования. **Плохо:** @@ -508,7 +508,7 @@ function parse(tokens: Token[]): SyntaxTree { Дублирование кода плохо, тем что если вам придется править логику, её придется править в нескольких местах. Представьте если вы открыли ресторан и ведете учет ваших продуктов: всех ваших томатов, лука, чеснока, специй и д.р.. -Если у вас закажут блюда из томатов то вам придется вносить изменения во все ваши списки. Если список будет только один +Если у вас закажут блюда из томатов, то вам придется вносить изменения во все ваши списки. Если список будет только один, то и править нужно будет только его. Часто вы дублируете код из-за того что когда вам требуется реализовать два и более незначительно различающихся действий, @@ -595,7 +595,7 @@ function showEmployeeList(employee: Developer | Manager) { Вы должны критически относиться к дублированию кода. Иногда существует компромисс между дублированием кода и увеличением сложности, вводя новую абстракцию. Когда две реализации из двух разных модулей выглядят одинаково, но существуют в разных -доменах, дублирование может быть приемлемым и предпочтительным вариантом, нежели объеденений в общий код. Перенос логики +доменах, дублирование может быть приемлемым и предпочтительным вариантом, нежели объединение в общий код. Перенос логики в общий код, вводит косвенную зависимость между двумя модулями. **[⬆ back to top](#содержание)** @@ -740,13 +740,13 @@ console.log(name); функция использующаяя `корзину` массив будет зависеть от этого добавления. Это может быть как хорошо, так и плохо. Давайте представим плохую ситуации: -Пользователь нажимает кнопку "Купить" вызывующюю функцию `purchase` которая делает сетевой запрос и отправляет `корзину` +Пользователь нажимает кнопку "Купить" вызывующую функцию `purchase`, которая делает сетевой запрос и отправляет `корзину` массив на сервер. Если происходит плохое подключение к сети функция должна отправить повторный запрос. Теперь, если пользователь случайно нажимает на кнопку "Добавить в корзину", но пока не хочет покупать товар? Если это произойдет и в этот момент начнется запрос на сервер, то функция purchase отправит случайно добавленный элемент, так как он имеет ссылку на корзину покупок, котора была изменена функцией `addItemToCart`. Путем добавления нежелательного элемента. -Хорошим бы рещением было бы что бы функция `addItemToCart` всегда клонировала бы массив `cart` редактировала его и +Хорошим бы решением было бы что бы функция `addItemToCart` всегда клонировала бы массив `cart` редактировала его и возвращала клон. Это бы гарантировало, что никакие другие функции, использующие ссылку на массив корзины покупок, не будут затронуты какими-либо изменениями. @@ -928,7 +928,7 @@ if (!isEmailUsed(node)) { Эта задача кажется невозможной. Большинство людей, впервые услышав это, говорят, "как я должен делать что-либо без выражения `if`?". Ответ заключается в том, что во многих случаях для достижения тех же целей можно использовать -полиморфизм. Второй вопро обычно, "хорошо, замечательно, но почему я должен их избегать?" Ответ, предыдущая концепция +полиморфизм. Второй вопрос обычно, "хорошо, замечательно, но почему я должен их избегать?" Ответ, предыдущая концепция чистого кода, которую вы узнали: функция должна выполнять только одну задачу. Когда у вас есть классы и функции, содержащие конструкцию `if`, вы говорите своему пользователю, что ваша функция выполняет больше одной задачи. Запомните, делать только одну задачу. @@ -1636,7 +1636,7 @@ class EmployeeTaxData { ### Используйте цепочки вызовов -Этот паттеррн очень полезен и обычно используется во многих библиотеках. Это позволяет вашему коду быть выразительным +Этот паттерн очень полезен и обычно используется во многих библиотеках. Это позволяет вашему коду быть выразительным и менее многословным. По этой причине используйте цепочку методов и посмотрите, насколько чистым будет ваш код. **Плохо:**