Pull to refresh

Comments 14

Главный вопрос: а при чём тут JS? Большая часть советов применима куда угодно.
Организуйте методы так, чтобы их можно было бы объединять в цепочки.

Очевидно нет. Это годится тогда и только тогда, когда сценарии использования этих методов предполагают эти самые последовательные вызовы многих методов.
Во всех остальных случаях методы не нужно организовывать в цепочки.
UFO just landed and posted this here

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

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

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

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

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

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

В нестрого типизированном языке этого не избежать :) Но лучше использовать все возможности языка, хотя бы очевидные. Например, преобразование типов на лету. Естественно, понимая, где это можно, а где лучше не устраивать кашу
UFO just landed and posted this here

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

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

Плохо:

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

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

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

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

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

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

Sign up to leave a comment.