Советы по чистому коду

Простые в использовании и короткие советы, собранные из многих статей, чтобы сделать наш код более читабельным и чистым 🙂

1. Используйте паттерн проектирования Return Early:

function saveItem(item) {
  if (item != null) {
    console.log("Validating");

    if (item.isValid()) {
      console.log("Saving item");
      item.save();
    }
}

В приведенном выше примере нет ничего плохого, но вместо вложенных операторов if, если значение элемента равно null или недействительно, мы можем использовать ранний возврат для выхода из функции следующим образом.

function saveItem(item) {
  if (item == null) return;

  console.log("Validating");
  if (!item.isValid) return;

  console.log("Saving item");
  item.save();
}

2. использование деструктуризации объектов для параметров функций

Предположим, у нас есть функция, которая принимает объект в качестве параметра и выполняет некоторую операцию над этим объектом, чтобы вернуть новое значение. Без использования деструктуризации объекта мы можем получить что-то вроде этого:

function getFullName(person) {
  const firstName = person.firstName;
  const lastName = person.lastName;
  return `${firstName} ${lastName}`;
}

Это создает две временные ссылки, firstName и lastName, даже если они нам на самом деле не нужны.

Лучший способ реализовать это — использовать деструктуризацию объекта. Мы можем уничтожить объект person, чтобы получить и firstName, и lastName в одной строке:

function getFullName(person) {
  const { firstName, lastName } = person;
  return `${firstname} ${lastName}`;
}

И мы все еще можем сделать этот код более элегантным, уничтожив параметры :).

function getFullName(person) {
  const { firstName, lastName } = person;
  return `${firstname} ${lastName}`;
}

3. Избегайте побочных эффектов, используя чистые функции:

При написании функции лучше всего избегать изменения переменных за пределами этой функции.

let items = 5;
function changeNumber(number) {
  items = number + 3;
  return items;
}
changeNumber(5);

Поскольку мы изменяем значение переменной item при вызове этой функции, такое использование приводит к нежелательным ситуациям.

Вместо этого мы можем переписать функцию следующим образом, используя чистую функцию.

function addThree(number) {
  return number + 3;
}

Поскольку мы удалили внешнюю переменную, поведение функции теперь полностью предсказуемо.

4. SRP (принцип единой ответственности)

Пишите короткие функции, которые делают только одну вещь.
Это означает, что код не должен иметь вложенной структуры или более двух уровней отступов.

Неправильное использование

function signUpAndValidate() {
}

Вместо этого:

function signUp() {
}
function validate() {
}

5. Используйте осмысленные имена переменных и функций:

** Функции выполняют действия, поэтому используйте глаголы при названии функций**.

// bad
function passwordValidation() {
}
// good
function validatePassword() {
}

Используйте множественное число для массивов

const animal = ["cat", "dog", "bird"];
const animals = ["cat", "dog", "bird"];

Используйте осмысленную номенклатуру при итерации функций обратного вызова

animals.forEach((a) => {
console.log(a);
});
// do this
animals.forEach((animal) => {
console.log(animal);
});

6. группируйте похожие переменные и функции, чтобы сделать ваш код многоразовым и понятным.

7. Принцип сухости:

Не повторяйтесь. Если вам нужно использовать один и тот же код в нескольких местах, превратите его в функцию.

8. использование пустых строк для создания читабельного кода

function saveItem(item) {
  if (item == null) return;
  console.log("Validating");
  if (!item.isValid) return;
  console.log("Saving item");
  item.save();
}
function Delete(item) {
  console.log("Delete item");
  item.delete();
}

function saveItem(item) {
  if (item == null) return;

  console.log("Validating");
  if (!item.isValid) return;

  console.log("Saving item");
  item.save();
}

function Delete(item) {
  console.log("Delete item");
  item.delete();
}

9. используйте модульное тестирование и внедряйте разработку, управляемую тестами (TDD):

Юнит-тестирование облегчает внесение изменений в код и уменьшает количество ошибок.

В разработке программного обеспечения существует процесс, называемый Test Driven Development (TDD), в котором требования преобразуются в конкретные тестовые случаи, а затем разрабатывается программное обеспечение для прохождения новых тестов.

☼ Занимайтесь дизайном
☼ Напишите тест
☼ Развитие письменной речи
☼ Пройдите тест

Процесс TDD включает следующие этапы;

В соответствии с заданными требованиями разработчик программного обеспечения пишет тестовый пример
Эти тесты выполняются, и ожидается, что они будут неудачными, поскольку они были написаны до разработки функции
Кодирование выполняется командой разработчиков для успешного прохождения теста
Все тесты гарантированно пройдут успешно
Код снова проверяется и редактируется. Проводится благоустройство или уборка

10. избегайте написания ненужных комментариев

Используйте осмысленные имена для переменных, функций или файлов, чтобы избежать ненужных комментариев в коде.

Когда вы собираетесь добавить комментарий, задайте себе вопрос: «Как я могу улучшить код, чтобы этот комментарий не был нужен?». Улучшите код, а затем задокументируйте его, чтобы он стал еще более понятным.
-Стив Макконнелл

11. Рефактор

Рефакторинг кода — это действительно хороший навык, он помогает вам понять, что происходит, и он становится лучше по мере рефакторинга, это всегда хорошая практика — вернуться к своему коду через некоторое время и улучшить его.

12. Держите все объявления переменных вместе:

Когда ваши проекты начнут расти, ваши классы, вероятно, будут иметь много переменных. Во-первых, следует держать все объявления переменных вместе в верхней части страницы или хотя бы где-нибудь — это ускоряет поиск.

13. Выберите правильную архитектуру

Существует множество парадигм и архитектур, которые вы можете использовать для построения своих проектов. Обратите внимание, что этот совет касается выбора подходящего для ваших нужд, а не выбора лучшего.

«Программирование без требований и дизайна — это искусство вставки ошибок в пустой текстовый файл».
Луис Срыгли

Например, модель Model-View-Controller (MVC) популярна в веб-разработке, поскольку она помогает сохранить организованность кода и призвана минимизировать усилия по обслуживанию.

14. Магическое число:

Магическое число означает, что мы присваиваем число, которое не имеет четкого значения. Иногда мы используем значение для конкретной цели и не можем присвоить его значимой переменной. Это приводит к тому, что человек, читающий ваш код, не понимает назначения этого числа.

//Bad practice
for(let i = 0; i < 50; i++){
    //do something
}
//Good practice
let NUMBER_OF_STUDENTS= 50
for(let i = 0; i < NUMBER_OF_STUDENTS; i++){
    //do something
}

15. использование шаблонов проектирования

Принципы проектирования SOLID

Принцип единой ответственности: Класс должен иметь только одну работу

Принцип «открыто-закрыто»: Класс должен быть открыт для расширения, но закрыт для модификации.

Принцип замещения Лискова: Объекты в программе должны быть взаимозаменяемы с экземплярами своих подтипов без изменения корректности программы.

Принцип разделения интерфейсов: Клиент никогда не должен быть вынужден реализовывать интерфейс, который он не использует.

Принцип инверсии зависимостей: Модуль высокого уровня должен быть основан на высокоуровневом обобщении, а не на низкоуровневой детализации.

Другие шаблоны проектирования

Принцип составления объектов: Классы должны обеспечивать повторное использование кода посредством агрегации, а не наследования.

Закон Деметры / Принцип наименьшего знания: Классы должны знать и взаимодействовать с как можно меньшим количеством других классов.

Абстракция: Упрощайте, показывая только необходимую информацию

Инкапсуляция: Группировка атрибутов и поведения в объект и раскрытие свойств, когда это необходимо.
Используйте инкапсуляцию, когда группа кода часто используется вместе.

Разложение: Разделение объекта на части, которые можно применять по отдельности.
Если класс слишком велик, используйте декомпозицию.

Обобщение: Факторизация общих свойств классов, которые могут быть повторно использованы в других местах.
Используйте обобщение, когда один и тот же код, с небольшими изменениями, используется в нескольких частях кодовой базы.

Связность и когезия: Свободно связанные модули менее зависимы и их легче использовать повторно, а высокая когезия описывает модуль, который имеет четкую цель и не сложнее, чем нужно.
Если изменение в одном месте вызывает изменение во многих других частях, это означает тесную связь.

Наследственность: Атрибуты или поведение, которые подклассы наследуют от суперкласса или реализуют через интерфейс.

Скрытие информации: Модули должны иметь доступ только к той информации, которая им необходима.

Скрытие информации (разделение обязанностей): Разные модули должны иметь разные заботы

Принцип KISS: Принцип KISS гласит, что большинство систем работают лучше, если их не усложнять, а упрощать; поэтому простота должна быть главной целью при проектировании, а излишней сложности следует избегать.

16. Правила Санди Метц

Классы не могут содержать более 100 строк кода
Методы и функции не могут содержать более 5 строк кода
К методу
передавать до 4 параметров
Контроллеры могут инициализировать только один объект

«Как разработчик, помните, что мы должны беспокоиться не только о доставке вещей. Это нечто большее, чем просто подумать о следующем разработчике, который должен поддерживать код. Поэтому, пожалуйста, оставляйте свой код в удобочитаемом виде, который вы захотите найти в своем следующем проекте.»

Ресурсы 🙂
Большое спасибо
☼ Доминик Дюк
☼ Лорен Александр
☼ Клаудия Санжуан
☼ Стив Макконнелл
☼ Ахмет Чокгунгорду
☼ Аведис Кеофтейан
☼ Амаль Хасни
☼ Кей Джан Вонг
☼ Джоэл Ли
☼ Шоаиб Мехеди
и
☼ https://www.geeksforgeeks.org/7-tips-to-write-clean-and-better-code-in-2020/
☼ https://www.pluralsight.com/blog/software-development/10-steps-to-clean-code?clickid=SKFQgUxRexyNT4OXXR3ok2jQUkDyfpWv5QPMyQ0&irgwc=1&mpid=29332&aid=7010a000001xAKZAA2&utm_medium=digital_affiliate&utm_campaign=29332&utm_source=impactradius
☼ https://en.wikipedia.org/wiki/SOLID
☼ https://en.wikipedia.org/wiki/KISS_principle