Привет, Хабр! Представляю вашему вниманию перевод статьи «Академия темного кода: переносы строк, интервалы и отступы» автор zhikin2207 
Привет люди! Позвольте мне продолжить рассказ о нашей академии плохого кода.
В этом посте мы покажем еще один способ замедлить чтение вашего кода.
Следующие методы помогут вам снизить понимание вашего кода и увеличить вероятность появления в нем ошибок.
Готовый? Давайте начнем.
Разрывы строк, пробелы и отступы могут убить.
Как люди читают книги? Сверху вниз, слева направо (по крайней мере, большинство).
То же самое происходит, когда разработчики читают код. Одна строка кода должна содержать одну идею, поэтому каждая строка должна содержать только одну команду.
Если вы хотите запутать других разработчиков, вам лучше нарушить эти правила.
И позвольте мне показать вам, как это сделать.
Пример №1 Посмотрите на этот фрагмент кода.
Одна идея в одной строке.
Код настолько чист, что меня тошнит.
Мы могли бы объединить все утверждения в одну строку, но это было бы слишком просто.return elements .Where(element => !element.Disabled) .
OrderBy(element => element.UpdatedAt) .
GroupBy(element => element.Type) .
Select(@group => @group.First());
В этом случае мозг разработчика поймет, что здесь что-то не так, и разобьет утверждения слева направо.
Проще простого! Некоторые утверждения лучше оставить в одной строке, а другие разделить.
В лучшем случае некоторые утверждения разработчик может даже не заметить, что приведет к недопониманию и в конечном итоге к ошибке.
Другой вариант: мы просто будем постепенно снижать его понимание этого кода, пока он не закричит: «Что это за черт!»!? return elements.Where(e => !e.Disabled)
.
OrderBy(e => e.UpdatedAt).
GroupBy(e => e.Type) .
Select(g => g.First());
Как вам это нравится? Можно добавить небольшой отступ, тогда другие разработчики будут десятилетиями форматировать ваш код, если им понадобится переименовать переменную elements. return elements.Where(e => !e.Disabled)
.
OrderBy(e => e.UpdatedAt).
GroupBy(e => e.Type) .
Select(g => g.First());
Отправьте мне открытку, если этот подход пройдет проверку кода в вашей команде.
Совет : Держите пару утверждений в одной строке и пару в отдельных строках.
Пример №2 Здесь точно такая же идея.
Это единственный код, который вы видите гораздо чаще.
var result =
(condition1 && condition2) ||
condition3 ||
(condition4 && condition5);
Процедура та же.
Разделяйте строки, чтобы максимально запутать читателя.
Поиграйте немного с символами новой строки, чтобы получить лучшие результаты.
var result = (condition1 && condition2) || condition3 ||
(condition4 && condition5);
И добавьте отступы, чтобы код выглядел нормально.
var result = (condition1 && condition2) || condition3 ||
(condition4 && condition5);
Помните: вы должны найти баланс между тем, чтобы сделать ваш код нечитабельным и правдоподобным в своем стиле.
Совет : поэкспериментируйте с символами новой строки, чтобы получить лучшие результаты.
Пример №3
Как насчет этого? if (isValid)
{
_unitOfWork.Save();
return true;
}
else
{
return false;
}
Та же проблема, но с другой стороны.
Лучшим вариантом здесь будет объединение операторов в одну строку, конечно же, с фигурными скобками.
if (isValid) { _unitOfWork.Save(); return true; } else { return false; }
Этот подход будет работать только в том случае, если в блоках «then» и «else» не так много операторов.
В противном случае ваш код может быть отклонен на этапе проверки кода.
Совет : объединить небольшие операторы if/for/foreach в одну строку.
Пример №4 80 символов в строке — текущий рекомендуемый стандарт. Это позволяет вам сосредоточить внимание разработчика, пока он читает ваш код. Более того, вы можете открыть два документа одновременно на одном экране, когда вам это нужно, и при этом останется место для обозревателя решений.
bool IsProductValid(
ComplexProduct complexProduct,
bool hasAllRequiredElements,
ValidationSettings validationSettings)
{
// code
}
Самый простой способ замедлить чтение вашего кода — заставить других разработчиков прокручивать ваш код по горизонтали.
Просто игнорируйте правило 80 символов.
bool IsProductValid(ComplexProduct complexProduct, bool hasAllRequiredElements, ValidationSettings validationSettings)
{
// code
}
Очень легко забыть, что было до того, как вы начали прокручивать или пропустить строку, с которой начали.
Отличный трюк.
Совет : Намеренно игнорируйте правило 80 символов.
Пример №5 Пустая строка в нужном месте — мощный инструмент для группировки кода и облегчения его чтения.
ValidateAndThrow(product);
product.UpdatedBy = _currentUser;
product.UpdatedAt = DateTime.UtcNow;
product.DisplayStatus = DisplayStatus.New;
_unitOfWork.Products.Add(product);
_unitOfWork.Save();
return product.Key;
Пустая строка в неправильном месте в сочетании с другими советами этой статьи может помочь вам сохранить работу.
Какую пустую строку вы предпочитаете? ValidateAndThrow(product);
product.UpdatedBy = _currentUser;
product.UpdatedAt = DateTime.UtcNow;
product.DisplayStatus = DisplayStatus.New;
_unitOfWork.Products.Add(product);
_unitOfWork.Save();
return product.Key;
Совет : Вставить пустые строки случайным образом.
Пример №6 Когда вы выполняете коммит в репозиторий, у вас есть крошечное окно возможности увидеть, что именно вы собираетесь коммитить.
НЕ ДЕЛАЙТЕ ЭТОГО! Ничего страшного, если вы добавите еще одну пустую строку, как здесь.
private Product Get(string key)
{
// code
}
private void Save(Product product)
{
// code
}
Или, еще лучше, добавили несколько пробелов в пустую строку (чтобы понять разницу, выделите 5-ю строку).
private Product Get(string key)
{
// code
}
private void Save(Product product)
{
// code
}
Зачем тебе это нужно? Код продолжает работать (но это не точно).
Вы продолжаете понимать свой код, но другой разработчик будет понимать его меньше.
Вы не можете просто добавить несколько дополнительных пробелов к общим методам сразу (проверка кода — наш враг), но использование этой практики создаст беспорядок уже через пару недель активной разработки.
Еще одним дополнительным преимуществом использования дополнительных пробелов в строке является то, что когда другие разработчики фиксируют соответствующие функции, их IDE может автоматически исправить форматирование.
При проверке кода они увидят тысячу красных и зеленых линий.
Если вы понимаете, о чем я ;) По той же причине вы можете настроить табуляцию в своей IDE, если используете в проекте пробелы, и наоборот. Совет : Не смотрите на код перед коммитом.
Пример №7 Избегайте тех разработчиков, которые могут увидеть в коде ненужные пробелы.
Они опасны для вашей карьеры.
product.Name = model.Name;
product.Price = model.Price;
product.Count = model.Count;
Совет : Знай своего врага.
Тяжелая работа делает ваш код неподдерживаемым.
Когда у тебя накапливается много мелких проблем, они растут без твоего участия.
Молодые разработчики будут писать свой код по вашим шаблонам.
Однажды во время проверки кода вы услышите: «Какого чертаЭ» от вашего тимлида, и здесь вы получите возможность использовать крылатую фразу: «Что? Мы всегда так делаем», и покажи ему тысячу мест в коде, где написано то же самое.
Веселиться.
Теги: #программирование #Ненормальное программирование #Идеальный код #стиль кода #чистый код #веселье #академия темного кода
-
«Здесь В Одиночку Далеко Не Уйдешь»
19 Oct, 24 -
Отчеты О Запуске Rad Studio Xe4
19 Oct, 24 -
Автоматическая Фотостудия, Часть 1
19 Oct, 24 -
Создание Симулятора Солнечной Системы
19 Oct, 24
