RUVDS.com corporate blog
Website development
JavaScript
Perfect code
Comments 14
+9
Главный вопрос: а при чём тут JS? Большая часть советов применима куда угодно.
Организуйте методы так, чтобы их можно было бы объединять в цепочки.

Очевидно нет. Это годится тогда и только тогда, когда сценарии использования этих методов предполагают эти самые последовательные вызовы многих методов.
Во всех остальных случаях методы не нужно организовывать в цепочки.
0

После Тараса КТЛ серьёзно воспринимать словосочетание "чистый код" не получается.

0
спасибо друг, посмотрел его контент ржал и умирал от смеха, анализ космического масштаба, рекомендую всем
0
Мне кажется что «Совершенный код. Мастер-класс» или «Чистый код: создание, анализ и рефакторинг» обязательны к прочтению для любого разработчика.
В свое время мне понравился доклад Кирилла Мокевнина "Ментальное программирование". Я еще не смотрел, но оказывается есть продолжение этого доклада. Он раскрывает там многие вещи, не привязываясь к языку.
+2
Много спорных моментов. В том смысле, что контекст может быть гораздо шире. Те же флаги иногда гораздо удобнее использовать для избежания дублирования кода. Или вот это:
if (isValid) {
  // что-то сделать...
}

может вынести мозг на какое-то время, если в аргумент придёт 0. Как и в этом примере:
if (value === "500") {
  console.log(value);
  // этот код выполнится
}

— если не выполнять сравнение типов (то есть просто использовать == вместо ===), то можно избежать некоторого головняка.

Короче, думайте, что вы хотите сделать, а не только используйте абстрактные правила «как лучше»
0

По мне, так неявное сравнение без учёта типов как раз добавляет головняка) потому что код может работать так, как не должен. То есть, если вы намеренно указали == вместо ===, это одно. Но часто бывает, что это делают по ошибке, по неопытности, а есть ещё запущенный случай, когда хотят покрыть все варианты данных. В итоге код работает на корректных и не корректных параметрах, а дальше по коду вполне может быть расчет на то, что переменная содержит один тип, а не несколько вариантов. И вот тогда начинается веселая прогулка с отладчиком)

0
В нестрого типизированном языке этого не избежать :) Но лучше использовать все возможности языка, хотя бы очевидные. Например, преобразование типов на лету. Естественно, понимая, где это можно, а где лучше не устраивать кашу
0
Все супер, я бы еще ES-модули добавил, плохо что они вышли так поздно — в ноде свои модули а Web вообще на TypeScript переползает.
+8

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

+1
Старайтесь не называть логические переменные так, чтобы в их именах присутствовало бы отрицание.

Плохо:

function isUserNotBlocked(user) {
// реализация
}

if (!isUserNotBlocked(user)) {
// реализация
}

Хм. А если я чаще использую проверку на то, что юзер НЕ заблокирован?

1) if (userNotBlocked)
2) if (!userBlocked)

Мне второй вариант кажется хуже. А первый оправдывает существование метода с Not.
Или я не прав?
+1
Избегайте использования длинных списков аргументов
Плохо:
function getUsers(fields, fromDate, toDate)
Хорошо:
function getUsers({ fields, fromDate, toDate })
Статья Пишем чистый и масштабируемый JavaScript-код: 12 советов, также от RuVDS:
При объявлении функции следует стремиться к использованию нескольких параметров, а не одного объекта с параметрами
Так как же лучше делать-то?
0

Справедливости ради: обе статьи есть перевод разных авторов. :)
Сколько людей, столько и мнений.

Only those users with full accounts are able to leave comments. , please.