Радикальный перфекционизм в коде

https://habr.com/ru/post/543490/
Вот прям до усрачки не согласен с автором. Такое ощущение, что если
где-то есть правило, то для него это перфекционизм и вообще радикальный.

    В конце каждого файла должен быть перевод строки.
    А если не будет, то кто умрёт?

Причём тут "умрёт кто-то или нет"? Но бесить не текстовый файл (по
POSIX, все строки должны заканчиваться переводом строки) это людей будет
ещё как. Автор, ты что-то будешь делать только если на кону чья то жизнь?

    Нельзя делать несколько statements на одной строке. Если я напишу $x
    = 1; $y = 1; $z = 1;, то читабельность ухудшится на 0.00001% и можно
    закрывать техотдел?

В итоге тьма способов (если и с пробелами до и после "=") написать одно
и то же и это одно сплошное удовольствие делать review кода в котором
нужно выискивать и интерпретировать глазами все эти инициализации
переменных.

Тут он инициализацию на одну строку сделает, тут пробелами красоту
наведёт, тут именование будет "b2c", а в другом месте
"BusinessToClient". В команде где я когда то работал даже уславливались
в тестах о порядке аргументов в assertEquals(): что идёт первым --
ожидаемое значение или сравниваемое. Или какие кавычки в этом Python
использовать (в каком нибудь Go для строк только двойные штатно, а
одинарными передают символы). Или кто в названиях функций/методов идёт
первым: глагол или объект. Ибо даже такие мелочи упрощают и увеличивают
скорость восприятия кода.

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

комментарий 0:

From: kmeaw
Date: 2021-02-25 08:29:53Z

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

Тогда все эти споры относительно стиля прекратятся - у каждого текст
программы будет выглядеть так, как ему нравится. Наверное, подобного
эффекта можно достичь и с обычным редактором, написав какие-нибудь
хитрые хуки для VCS.

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

> в тестах о порядке аргументов в assertEquals(): что идёт первым --
> ожидаемое значение или сравниваемое

Хорошо, конечно, с теми языками, где авторы навязывают своё мнение
относительно стиля. Мало кто из Go-разработчиков, например, будет
спорить с go fmt.

комментарий 1:

From: Sergey Matveev
Date: 2021-02-25 09:20:01Z

*** kmeaw [2021-02-25 11:21]:
>Было бы здорово, если бы редактор, в котором разработчик пишет код, был
>не текстовым редактором, а редактором AST, но с сохранением особенностей
>стиля для каждого узла.

Да, было бы интересно как это будет на практике. Ну в смысле может это
действительно будет неким Святым Граалем и концом споров. LSP сервер мог
бы в этом помогать.

Мне вот понравился clang-format который одним вызовом глобально весь
стиль может поменять. И если не было "// clang-format off", то оно
туда-сюда без потерь преобразует Си код. И действительно можно бы им
было преобразовывать как удобно для себя, а перед коммитом в то, что
нужно в upstream репозитории. Но с редактором это бы не сравнилось
конечно.

>Хорошо, конечно, с теми языками, где авторы навязывают своё мнение
>относительно стиля. Мало кто из Go-разработчиков, например, будет
>спорить с go fmt.

За всю жизнь я вроде бы только один раз отключал (если не путаю, но
вроде fmt можно для участка кода отключить комментариями) fmt, где
всякие таблицы констант были. А так да -- здорово что всё всегда
выглядит одинаково.