Писать понятный код.

Рано или поздно любому разработчику приходится оценивать чужой код. Хорошие программисты могут интуитивно оценить код, но далеко не всегда аргументированно могут обьяснить почему. И вот тут начинаются определения, вроде «понятный», «интуитивный» или «хороший». Казалось, и хрен бы с ними, но вот такие программисты рано или поздно начинают проводить собеседования или насаждать решения в проекте. И вот тут начинается жопа. Остальные, менее опытные программисты начинают подстраиваться под субъективное качество кода, а собеседования проходят только те, кто смог подстроится под «можно лучше».

1. Всё, что можно превратить в строгие правила, нужно превращать. Паттерны, линтеры, покрытие тестами, числовые значения — подходит всё, что не зависит от субъективного мнения.

2. Любая дискуссия о качестве кода должна быть о нарушении правил или о расширении набора правил. «Вот так вот лучше» с куском кода в комментариях к пулл реквесту писать нельзя.

3. Любую задачу можно решить несколькими способами.