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

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

Несмотря на то, что мир разработки не идеален, мы все равно хотим, чтобы он был совершенным, и хотим, чтобы наши коллеги тоже были совершенны, так что разве не удивительно, что мы можем использовать автоматизированные инструменты для достижения совершенства? Линтеры берут это руководство по стилю и упорно следят за соблюдением правил. Вам не разрешат отправлять код в репозиторий, если он нарушает правила. Теперь все разработчики кодируют по одному стандарту. Они должны.

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

Кроме…

Совершенство было бы руководством по стилю, написанным и согласованным в команде, и мы знаем, что это почти никогда не работает так. Один или, может быть, два разработчика, но обычно только один, получают возможность навязать остальной команде свой собственный стиль программирования. Не любите точки с запятой в javascript? Как 2 пробела вместо табуляции? Вы можете выбирать, и все должны следовать за вами. Такая власть, которую можно дать одному разработчику, и вы можете поспорить, что большая часть команды, над которой они владеют, возмущается ею каждый день.

Линтерам, как и всем автоматизированным инструментам контроля качества кода, не хватает нюансов. У них есть строгие правила, и в них нет места контексту. Можете ли вы представить себе использование чего-то подобного при написании?

Слово «the» всегда должно начинаться с большой буквы и ставиться точка.

Абзацы не могут превышать 8 строк.

Вопросительные знаки могут заканчивать только предложения, начинающиеся со слов «Что», «Почему» или «Кто».

Восклицательные знаки не допускаются.

Конечным результатом будет точка, в которой пунктуация просто соответствует стандартам линтера и ничего не добавляет к смыслу текста. Как вы можете вывести какое-либо значение из присутствия этой запятой, если вы знаете, что запятая здесь, потому что она требуется линтеру?

То же самое относится и к коду, который был подвергнут линтингу. Вы не можете сделать вывод о логике кода по тому, как разработчик сделал отступ или разбил его пустыми строками, потому что точное количество пробелов и пустых строк предопределено. Код выглядит красиво и последовательно, он выглядит как хороший код. Я бы сказал, что это самая большая проблема с линтингом. Разработчик, который пишет неуклюжий код, будет писать код, который выглядит неуклюжим, даже если он пытается придерживаться руководства по стилю. Просто взглянув на файл кода, вы можете предсказать вероятное качество кода по их подходу к его размещению. Линтинг маскирует это налетом компетентности, в то время как сам код все еще может вонять.

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

Мы знаем, что хорошие разработчики пишут код, который выглядит красиво и имеет смысл в том, как он организован. Линтинг делает код выглядящим как хороший код, но совершенно точно не делает его хорошим кодом.

А если вы хотите, чтобы весь код выглядел так, как будто вы его написали? Возможно, вы не готовы к работе в команде.