Несекретная формула того, как сделать свой код лучше

3
2083
views

Перевод статьи Тала Березнитского «The Non-Secret Formula for Writing Better Code».

Последовательность в коде

Предупреждение: все в этом посте — мое личное мнение. Но все равно это на 100% правда, можете не сомневаться.

Мне нравится писать чистый код. Я хочу, чтобы моя команда также писала хороший и чистый код. Проблема в том, что каждый по-разному понимает словосочетание “чистый код”. Здесь представлена моя несекретная формула написания чистого кода, ведущая к уменьшению количества багов, более легкому внесению изменений и к повышению уровня счастья у разработчика.

Что такое “чистый код”?

Мне нравится работать с кодовыми базами, ориентированными на:

  • Читабельность. Код должен быть легким для чтения и понимания. Все “почему” и “как” в коде должны быть ясны.
  • Простоту. Программируйте просто. Это не о том, что код должен легко читаться. Код прост, когда его сложно использовать неверно. И когда его не сломаешь, добавляя новые возможности.
  • Единообразие (последовательность). Единообразные отступы. Последовательное присвоение имен. Последовательная структура файлов. Не важно, какой у вашего кода стиль, парадигмы и решения – главное, пусть они будут последовательными.

Как можно сделать свой код лучше?

Вот как я программирую сегодня и почему я делаю именно так.

Меньше комментариев

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

// 😞
if (x > 5) { // 5 is a special point where we must run away
   runAway()
}
// 👍
const runAwayThreshold = 5
const shouldRunAway = (x > runAwayThreshold)
if (shouldRunAway) {
   runAway()
}

Никаких «TODO»

Ваша кодовая база это не система управления проектом. JIRA, Trello, Asana (и другие) гораздо лучше подходят для планирования будущих работ. Да, даже этих «Мы должны ускорить эту функцию». Если это обязательно нужно сделать – держите эту запись там, где каждый сможет ее увидеть.

// 😞
while (true) {} // TODO: make this code faster when we have time
// 👍
while (true) {}

Самодокументированный код

Использование переменных может помочь коду стать самодокументированным. Мы можем использовать переменные для лучшего выражения наших намерений. Имя переменной должно отвечать на вопрос «почему?», а присваивание ей значения – на вопрос «как?».

// 😞
if (x > 2 && x < 5) { fireMissiles() } // 👍 const enemyInRange = (x > 2 && x < 5)
if (enemyInRange) {
   fireMissiles()
}

Ранняя разбивка

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

В целом правило таково: чем меньше отступов, тем более читабелен код.

// 😞
const fetchData = (id) => {
  if (id) {
    fetch('/data/' + id)
  }
}
// 👍
const fetchData = (id) => {
  if (!id) {
    return
  }
  fetch('/data/' + id)
}

Иммутабельные ссылки

Я предпочитаю ссылки const изменяемым ссылкам (let или var в JavaScript). Потому что так мне нужно один раз понять, что это за переменная, и можно к этому больше не возвращаться. Для этого я нахожу маленькие фичи в языках (не важно, в каком именно языке).

// 😞
let mul = x * y
if (mul > 70) {
  mul = 70
}
// 👍
const mul = Math.min(x * y, 70)

Еще пример:

// 😞
let x
if (str === 'one') {
  x = 1
} else if (str === 'two') {
  x = 2
} else if (str === 'three') {
  x = 3
}
// 👍
const x = {
  one: 1,
  two: 2,
  three: 3
}[str]

Одна цель – одна строка кода

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

// 😞
people
  .filter(person => person.age > 10 && person.firstName.length > 2 && person.lastName.length > 4)
// 👍
people
  .filter(person => person.age > 10)
  .filter(person => person.firstName.length > 2)
  .filter(person => person.lastName.length > 4)

«Погодите! А как насчет изменения производительности?». Мне это безразлично. Правда. Разве что есть реальная проблема, когда приложение становится медленнее, чем ожидалось.

Согласны или нет?

Я уверен, есть разработчики, у которых может быть свое мнение (отличающееся от моего) по каждому из этих пунктов. Поделитесь в комментариях!



3 КОММЕНТАРИИ

  1. Признак «чистой функции» — зависимость её результата только от входных параметров не невоздействие из неё на иной контекст.

  2. Последнее улучшение нецелесообразно с точки зрения производительности.
    3 filter — создание 3 новых массивов.
    Вот так нормально.

    «`js
    people.filter(person =>
    person.age > 10
    && person.firstName.length > 2
    && person.lastName.length > 4
    )
    «`

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here