Ну, может, это чуток преувеличено. Но когда вы на старте новой работы или проекта, когда вы входите в новую команду, вам и правда может помочь следование некоторым рекомендациям. Тут не нужна целая книга, страницы хватит. Но на этой странице есть вещи, на которые стоит обратить внимание.
Я представлю вам несколько из них. Собственно, обязательными я считаю всего три. Остальные меня не беспокоят. Забудьте, например, о префиксах. Если чувствуете потребность добавлять «str» или «f» или «m_» перед своими переменными, – делайте это. Если вы прибыли из мира C++ и просто не можете забыть его стиль, то и ладно. Но, пожалуйста, не игнорируйте следующие рекомендации.
KISS или, иначе говоря, простота
Да, я знаю, что вы уже слышали это тысячу раз и вот опять кто-то восхваляет это правило. «Краткость и простота» или «Упрощай, тупица» (англ. Keep it simple stupid – KISS). Это и впрямь одно из трех самых топовых правил.
Я знаю, регулярные выражения такие классные, а вы используете бинарные флаги вместо простых булевых, вы же отличный программист! А это что? Вы вырезали этот 30-строчный метод до 5 строк, но добавили 10 строк комментариев, потому что через неделю этот алгоритм не поймет никто, включая вас? Не надо так.
Вам известно, что такое хороший код? Это код, который всем понятен. Это и впрямь просто. Конечно, есть исключения. Используйте этот стандартный сниппет регулярных выражений, если хотите проверять вводимый адрес электронной почты и, может быть, используйте бинарный для вашей системы управления правами. Но пожалуйста, пускай это будут исключения.
И это касается не только упомянутых техник. Когда думаете об алгоритме и вам кажется, что он слишком простой, недостаточно блестящий, – немедленно остановитесь и используйте именно тот алгоритм, который уже есть в вашей голове прямо сейчас! Если его можно улучшить, вы всегда можете это сделать после рефакторинга вашего кода. Но подумайте о том, что другие люди – даже вы сами в будущем – будут в конечном итоге читать ваш код, а они не хотят опять иметь сложности, продираясь сквозь ваши хитроумные строки.
Держитесь простоты. Правда. Используйте ваши if-обороты, делайте это с помощью foreach, если думаете, что так легче читать. Но никогда не доходите до точки, где вы захотите быть фокусником, не желающим разоблачать свои трюки, чтобы никто не знал, как вы это делаете.
Покажите ход ваших мыслей коллегам. Спасибо.
Нейминг
Роберт С. Мартин уже давно сказал это в своей книге «Agile Principles, Patterns, and Practices in C#» и я тоже думаю, что это очень важно: давайте своим переменным, методам и классам имена, не нуждающиеся в дополнительных комментариях в документации.
Опять же, бывают исключения. Например, нет ничего дурного в «int i» в вашем for-цикле. Но если вы перебираете список пользователей с помощью foreach, не используйте просто «u». Назовите переменную для текущего пользователя «user». Или даже лучше – «currentUser». Почему бы и нет? Это сильно сложно? Вы потеряете слишком много времени на написание чуть более длинного имени? Но я действительно не переношу все эти одиночные буквы в качестве имен переменных. Что это за объект «о»? Или строка «str»?
То же касается названий методов: наведите меня на мысль о назначении этого метода. GetUserName() должен давать мне имя пользователя и возвращать его. PutUserProfile() должен вызывать веб-сервис и менять информацию в профайле пользователя. И не больше.
Если вы раздумываете над методом, который будет называться RegisterNewUserAndSendConfirmationMail(), вам стоит подумать о рефакторинге вашего кода, что приводит нас к последней важной рекомендации.
Строки кода
Не поймите меня неправильно. Количество строк никогда не может служить мерилом качества кода. Я не об этом говорю в данном разделе. Дело не в том, насколько мал ваш код, дело в том, насколько велики ваши методы и классы.
Говорят, методы не должны превышать размер вашего экрана. Это не слишком точное определение. Скажем, в ваших методах должно быть не больше 30 строк, а в ваших классах — от 500 до 1000 максимум. Это не означает, что можно взять метод на 300 строк и просто разбить его на 10 последовательно пронумерованных методов. Нет!
Это правило должно заставить вас задуматься. Это больше, чем дизайн. Вас никто не уволит, если у вас в методе 31 строка. Но вам стоит всегда спрашивать себя, нельзя ли сделать так, чтобы ваши методы и классы соответствовали этой рекомендации.
Посмотрите на приведенный выше метод, регистрирующий нового пользователя и отправляющий ему письмо с подтверждением. Вы, наверное, уже догадались, что из него вполне можно сделать два метода. Даже лучше: можно встроить метод SendEmailConfirmation() таким образом, чтобы его могли использовать другие методы или даже ваши коллеги.
Как я уже говорил, это скорее рекомендация обдумать дизайн правил и шаблонов. Для одного поста этого хватит. Запомните эти три основные правила, касающиеся написания кода:
- Простота
- Разумный нейминг
- Короткие методы и классы
Если вы мне все еще не верите, подождите, пока вам придется вносить изменения в класс, в котором 60 тыс. строк кода. 60 тысяч. Я серьезно. Не делайте так, как тот программист. Спасибо.
***
Подписывайтесь на наш канал в Telegram!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]