Это было жестко. Извините, но, скорее всего, это правда. Я работал в нескольких различных технологических компаниях и встречался с несколькими разными разработчиками. У каждого разработчика есть свои дурные наклонности.

Я встречал людей, которые писали слишком большие методы, людей, выбирающих неправильные типы данных, людей, использующих числа с плавающей запятой в качестве валюты, и людей, которые не писали модульные тесты с тех пор ... когда-либо!

Не то чтобы я тоже ангел. Я написал много плохого кода, но в последние несколько лет я написал исключительно хороший код, поскольку следую некоторым основным правилам.

Идеальный метод должен обладать следующими чертами

  • Маленький. Чем меньше, тем лучше.
  • Одноцелевое. Метод должен делать только одно.
  • Имена должны быть информативными. Хороший метод называется тем, что он делает. Не start (String arg, логическое продолжение). Должно быть очевидно, что делает метод, не глядя на тело метода.
  • Без аргументов. По возможности метод не должен принимать аргументов. Если нужно, сделайте это, но не более двух. Три и более аргумента - это недопустимо!
  • Без скрытых функций. Метод с именем checkPassword (String username, String password) не должен выполнять вход пользователя в систему, устанавливать временную метку последнего входа в систему и делать что-либо, кроме проверки правильности пароля данного пользователя.
  • Выбрасывать исключения. Не бойтесь исключений. Лучше выбросить исключение, чем возвращать код ошибки.
  • Напишите модульные тесты. Код более удобен в обслуживании, если вы пишете модульные тесты. Вы не боитесь менять код, когда юнит-тесты могут заверить вас, что метод не изменился в худшую сторону.

Также вам следует выбрать стиль для вашего кода. Лично я следую стилю PSR-2 всякий раз, когда пишу PHP. Это делает код более читабельным.

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

Могу привести отличный пример. Допустим, у вас есть форма регистрации, и вы требуете, чтобы пользователи указали свой CPR (датский номер социального страхования) при регистрации. Самостоятельно проверять числа было бы бессмысленно, так как пакет для этого я создал в Composer. Мой пакет уже делает то, что вы хотите, в нем есть модульные тесты и качество кода 10/10 по решению Scrutinizer.

Если вы хотите узнать больше о хороших привычках кодирования, я рекомендую Clean Code Роберта К. Мартина.