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

    Идея взята с постов telegram-канала Cross Join


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

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

    Бред, правда? Ну да, слишком радикально. Пусть в целом люди ходят как хотят, и чувствуют себя хорошо. Исключительные ситуации нужно решать частным порядком (уволить хулигана?), ну в крайнем случае ввести правило, что кроме белья должно быть что-то еще.


    И правда, бред. Ну а зачем тогда мы сами себе вводим бешеный фашизм в коде?


    Слишком жесткие правила


    Посмотрите правила code style. Стандарт PSR-12, например.


    Вот несколько пунктов:


    1. В конце каждого файла должен быть перевод строки. А если не будет, то кто умрёт?
    2. Нельзя делать несколько statements на одной строке. Если я напишу $x = 1; $y = 1; $z = 1;, то читабельность ухудшится на 0.00001% и можно закрывать техотдел?
    3. Declare statements MUST contain no spaces and MUST be exactly declare(strict_types=1). Ох, как всё серьёзно. Ни одного пробела, причем слово MUST капсом, чтобы все понимали степень ответственности. Если вставить где-нибудь пробел, то на код ревью никто код же прочесть не сможет!

    Но блин, если один чудак однажды написал под воздействием каких-то веществ


    declare(        strict_types                                              =1         )

    то это еще не значит, что надо ВСЕХ бить плёткой ругать линтером за каждый пробел. Нужно просто вправить мозг ОДНОМУ чудаку. Готов поспорить, что именно он тогда пришел на работу без трусов.


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


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


    Понятно, что есть способы автоматически отформатировать код по правилам. Вопрос в другом: какие правила нужны, а какие нет.


    Почему это важно


    Дома, когда ты пилишь свой pet-проект, ты используешь язык тот, какой хочешь, форматируешь код, как хочешь, структурируешь код, как хочешь. Точно не будешь надевать галстук.


    И перформишь при этом как бог! Совершенно спокойно можно все выходные провести за кодингом и особо не устать.


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


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


    К примеру, в Go есть goimports, который форматирует код по стандарту, вшитому в стандартный тулинг. Казалось бы, о чем тут теперь спорить. Но все равно внезапно обнаруживаешь себя, переименовывающим getJson в getJSON и getById в getByID, иначе правило линтера N100500 скажет айайай. При этом читабельность если и меняется, то незначительно, и даже не ясно, в какую сторону.


    Куча такого. Ладно код стайл, бог с ним. Давайте не будем на нем акцентировать внимание, это не настолько серьёзная проблема. Но ведь есть тысячи других радикальных штук. Договорились, что контроллеры тонкие, не содержат никакой логики — и всё, даже убогий код в контроллере из пары строк где-то в богом забытой части системы порождает споры на код ревью — является ли это логикой или нет.


    Дофаминовый цикл "сделал задачу — получил удовлетворение" нарушен. Сделал задачу — получи звиздюлей от линтера и коллег на код ревью.


    Дофамин еще полбеды. Возведение принципов программирования (тех же DRY или SOLID) в радикальный абсолют может привести к таким абстракциям, что код превращается в нечитабельное месиво. Увидел пару switch case — сразу городи иерархию классов. Так ведь в книжке написано.


    Мы ругаем бешеный принтер, ограничивающий свободу, но сами часто действуем по принципу "запретить и не пущать".


    Вообще, иногда хочется пересмотреть вообще всё. Например, однажды мы думали, как назвать по-английски переменную для ЦФО (центр финансовой ответственности). Словарь говорит, что это будет financial responsibility center. Если назвать переменную "FRC", то новичку будет непонятно, что это за хрень. В документации по продукту термин везде по русски, ЦФО. Если назвать financialResponsibilityCenter, то можно догадаться, о чем речь, но слишком длинно как-то.


    Понятно, что никто не рискнет так делать, но идеально было бы так и назвать переменную русскими буквами — ЦФО. Если проект сугубо для русскоязычных людей и русскоязычных программистов, то почему нет? Просто потому что не принято, вот и всё. Рациональных причин мало, и с ними можно поспорить, как минимум в каком-то конкретном случае.


    Вывод


    Я считаю, что:


    Придумывая универсальное правило, нужно убедиться, что оно точно капец необходимо.

    Применяя универсальное правило, нужно смотреть на контекст, и уметь делать исключения. Потому что совсем универсальных правил не существует.

    UPD. Для джуниор-программеров правила должны быть более жесткими, потому что важность читабельности кода для них может быть не столь очевидна.


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

    Средняя зарплата в IT

    120 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 3 288 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 203

      +31

      Правила нужны не для того, чтобы штамповать код быстро — они нужны, чтобы мозг не взрывался при попытке добавить к этому коду что-нибудь спустя год. Возможно, уже другим людям.

        –6
        да, но, скажем от одного пробела мозг не взорвется.

        Понятно, что какие-то правила нужны. Но куча же правил с недоказанной нужностью
          +12
          От одного пробела мозг не взорвётся. Но всякие там правила вроде «не больше одного оператора в строке» вполне себе нужны, особенно если в команде есть джуны. Да и вообще, весьма хорошая практика иметь единый стиль оформления кода во всей компании, это просто удобно. Программистам же на самом деле это ничуть не мешает. Эти правила никак не усложняют написание кода, но впоследствии заметно упрощают его чтение и сопровождение.
            +3

            Насчет джунов — это важная мысль. Дополню статью.

              0

              Ну почему же сразу джуны?
              Как только дело доходит до отладки и надо поставить брекпоинт — а его, внезапно, все могут ставить на строчку, и "не только лишь все" на отдельные операторы — так и приходит озарение.
              Порой и сложное выражение в условии с той же целью хорошо разбить на несколько строк.

                +1
                Ваш пример с брейкпоинтом. В строке $x=1; $y=1; $z=1; нечего отлаживать. А если вдруг в каком-то сложном случае это будет нужно, ну поставил там перевод строки, да и всё.
                  0

                  Речь как раз о том, чтобы НЕ ЗАНИМАТЬСЯ отдельно вставкой переводов строки. Пусть они сразу там стоят. А для этого лучше, если это правило будет в код-стайле.
                  Вы же пишете статью "в общем", не указывая язык программирования. Поэтому кроме python/php/javascript это может быть и С/С++, где вставка перевода строки подразумевает последующий билд и перезапуск. И если на локальной машине в любимой IDE это просто, как "два пальца", то на удалённом хосте у клиента, где есть только собранный бинарь и отладочные символы, это уже легко превращается в приключение. Поэтому — лучше заранее. Компилятор пробелы всё равно не считает, отладочные символы с информацией о дополнительных строчках всё равно нужны лишь для отладки — но если это недосмотрели, то раунд ребилда/редеплоя не очень обрадует.

                    0
                    Если в строчке возможно понадобится дебаг, и еще и ребилд при этом нужен, то это будет важным правилом, и я только за.

                    Но в каких-то проектах оно может быть лишним
                      0

                      Конечно!
                      В Вашем примере могу предположить, что это php.
                      Но, например, в C++ (да может быть и в том же php) в случае, если x,y,z — это не 'new shiny' переменные, а какие-нибудь ссылки на другие сущности, которые через грязные хаки в этот момент кто-то меняет из других потоков — всегда приятно, когда оно оказывается разбитым по строчкам. Если уж код сам по себе настолько плох, но хоть тут есть подстеленная охапка соломки — оно уже поддерживает охоту жить ).

              +4

              Настройте форматирование в ide и заведите привычку нажимать на хоткей перел коммитом. Пять минут времени и никаких пробелов

                –5

                Для нужных правил это ок. А для ненужных — непонятно зачем они вообще существуют

                  +15
                  Для нужных правил это ок. А для ненужных — непонятно зачем они вообще существуют

                  Они существуют, чтобы код был одинаковым у всех, кто работает по данному стандарту. А не потому что так писать код правильнее. Единообразие — знакомо такое слово?

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

                  Фактически это не правила, а договоренности. Если договоренности не охватывают каких-то аспектов, то грош им цена.

                    0
                    Хорошо нам на Джаве.
                    Достаточно вписать в конец правил — Все остальное должно соответствовать автоформату Идеи. И все. Все случаи покрыты. Не надо городить кучу правил на все мелочи и корнер кейсы.

                    Сознательно вредительсво не рассматриваем.
                      +1
                      Мне сейчас в мире Джаваскрипт очень комфортно. Вообще не надо ничего городить. Просто беру рекомендованные: 'plugin:vue/vue3-strongly-recommended', 'eslint:recommended', '@vue/typescript/recommended' и меня все устраивает, даже исключений не приходится делать. И очень зашел prettier. Я вообще перестал форматировать что-либо сам. А IDE само все делает, у меня например в момент сохранения.
                        +3

                        Правила форматирования прекрасны, когда поддержаны инструментом, который не бьет программиста по рукам, а одной кнопкой приводит форматирование к правильному

                        –1
                        Единообразие имеет ценность не само по себе а для какой-то цели, и только в определенных рамках.

                        Правила переноса фигурных скобок — да, важны.
                        А писать declare(strict_types=1) или declare(strict_types = 1) — вот воообще наплевать.

                        Согласны или нет?
                          +1
                          А писать declare(strict_types=1) или declare(strict_types = 1) — вот воообще наплевать.
                          Согласны или нет?

                          В абстрактом мире это конечно не важно. И если вы один работаете. А если вы в команде и используете version control system, то это правило важно, как и все другие.
                            0

                            Так если VCS используется, то виноват не тот, кто к правилу раслабленно относится, а тот, кто коммитит содержательные изменения вместе со стилевыми. Ну просто несопоставимо. И если претензии к тому, кто пробелы не так ставит, лично я сочту придиркой (ну, если это не совсем уж кровь из глаз с отягчающими обстоятельствами), то коммит со стилевыми правками вперемешку с содержательными — это уже реально очень крутой продолб.
                            Я где-то выше уже писал, что если не нравится чей-то не соответствующий общепроектному стиль — то возьми и поправь, и закоммить отдельным коммитом, причем по возможности убедившись, что ни в чьих ветках не будет проблем слияния.

                            0
                            Проблема, полагаю, как раз в автоматическом форматировании. У одного IDE удаляет пробелы, у второго добавляет, а теперь представьте что одному нужно что-то изменить в коде другого.
                        +1

                        Это не совсем хороший момент: можно намешать в один коммит и значимые правки, и форматирование. Так что лучше еще и до первой своей правки в файле форматнуть и закоммитить

                          0

                          Так и вправду лучше. Я скорее имел в виду, что проблема "страшного ужасного форматирования, лишних пробелов и табов" кажется надуманной в мире, где IDE в подсказказ разве что еще со стек оверфлоу код не предлагают тебе скопипастить (это, я думаю, не за горами уже:)

                          +1
                          В нормальных компаниях код просто не пройдет коммит если линт ругается.
                          Ну и хук стоит для авто формата
                            +1
                            В нормальных компаниях код просто не пройдет коммит если линт ругается.

                            Как раз недавно была ситуация — надо было заменить реализацию ф-и на заглушку (ну т.е. вместо того, что там было, возвращать некоторую константу, это было актуально, естественно, исключительно для дев-ветки). При этом было линт правило — никаких неиспользуемых аргументов в ф-и! Понятное дело, что замена на заглушку приводила к неиспользуемым аргументам. А удаление аргументов, в свою очередь, приводило к ошибкам типов при вызове этой ф-и (на вызове аргументы-то были). Исправление тех ф-й — опять-таки каскадно приводило к неиспользуемым аргументам и ошибкам типов, в итоге, чтобы удовлетворить линт, коммит на 1 строчку легким движением руки превращается в коммит на несколько сотен строк. Иначе — коммит НЕ ПРОХОДИТ, ведь "в нормальных компаниях код просто не пройдет коммит если линт ругается".
                            Большая польза от этого всего, действительно, превратить минутную работу в часовое ковыряние в коде.
                            С другой стороны — время оплатит заказчик, а потому любой подход, который раздувает трудозатраты, полезен.
                            Если есть возможность проект, который делается год, делать три года — то какой смысл от нее отказываться? Это же просто не выгодно! Так что больше линт-рулзов — хороших и разных! А когда заказчик спросит — чо так долго? можно ему популярно объяснить, что вот смотрите сколько у нас линт-правил, пока все выполнишь… ух!

                              +1
                              Как раз недавно была ситуация — надо было заменить реализацию ф-и на заглушку (ну т.е. вместо того, что там было, возвращать некоторую константу, это было актуально, естественно, исключительно для дев-ветки). При этом было линт правило — никаких неиспользуемых аргументов в ф-и!

                              Я работаю на C# и там любое правило можно на время или вообще навсегда отключить аттрибутом SuppressMessage именно в том месте где это надо. Как в других языках не знаю.

                                0

                                С одной стороны это неплохо, с другой стороны если заранее настраиваться на то, что по коду повсеместно будут расставляться SuppressMessage — не вполне понятно зачем вообще код проверять...

                                  0

                                  SuppressMessage надо ставить либо на время (как в примере с unused parameter), либо если действительно есть какие-то причины для того, чтобы нарушить правило линтера. И к нему всегда следует писать обоснование (свойство Justification). Что интересно, что у самого линтера C# есть в свою очередь правило, которое запрещает вставлять SuppressMessage с пустым Justification. А еще удобство в VS — в окне Errors можно включить фильтр который сразу же покажет все "подавленные (suppressed)" предупреждения.

                                  0
                                  Я работаю на C# и там любое правило можно на время или вообще навсегда отключить аттрибутом SuppressMessage именно в том месте где это надо. Как в других языках не знаю.

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

                                    +1

                                    Причин может быть много и вполне обоснованных, а не таких как "да надоел мне уже этот ворнинг". Например, берем проект ASP.NET Core, включаем FxCop, и, как правило, сразу же получаем ворнинги на то, что методы в Startup (ConfigureServices и Configure) нестатические (а статическими их сделать нельзя, т.к. сам фреймворк ожидает методов экземплярных). Или, например, строковые литералы, которые линтер будет требовать убрать из кода в ресурсы, хотя вы свое приложение не собираетесь никогда локализовывать. Или параметр метода, который из-за изменений в реализации стал неактуален, но какой-либо сторонний код совсем другого проекта все равно ожидает его наличия.

                                      0
                                      Причин может быть много и вполне обоснованных, а не таких как "да надоел мне уже этот ворнинг".

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

                                        0

                                        Затем, что в одном случае есть причины, чтобы его обходить, а в другом случае его лучше соблюдать.

                                          0
                                          Затем, что в одном случае есть причины, чтобы его обходить, а в другом случае его лучше соблюдать.

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


                                          алсо, если правило надо то соблюдать, то не соблюдать — то разве не лучше тогда его просто отключить? И пусть каждый сам решает в каждом месте — надо это правило соблюдать или нет. Без дополнительных церемоний. Нет?

                                            0

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

                                              –1
                                              алсо, если правило надо то соблюдать, то не соблюдать — то разве не лучше тогда его просто отключить?

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

                                            0
                                            но кроме этого?
                                            Невроз. Многие натурально получают наслаждение от исполнения ритуалов. И будут визжать до пены, защищая их от любого разумного человека, пришедшего с вопросом «зачем». Я с такими встречался в реальности, и это страшно (люди плакали, угрожали и т.д.).

                                            Они не могут без правил, например, в каждом файле они начинают реально ЗАДУМЫВАТЬСЯ, как правильно расставить пробелы в «declare(strict_types=1)», и так с каждой мелочью. И для них это реально пытка, когда нет правил на абсолютно всё.
                                              0
                                              Они не могут без правил, например, в каждом файле они начинают реально ЗАДУМЫВАТЬСЯ, как правильно расставить пробелы в «declare(strict_types=1)», и так с каждой мелочью.

                                              Один из плюсов следования единному coding style это как раз чтобы не задумываться о каждой мелочи при форматировании или именовании.

                                                0
                                                Ещё чтобы не задумываться о каждой мелочи, можно о ней просто не задумываться. У меня получается.
                                                  0

                                                  Про code review, я так понимаю, ты тоже не задумываешься, потому что у вас его нет?

                                                    +1
                                                    А у вас code review — для подсчёта пробелов? А то я всегда на содержание смотрю в первую очередь. С вашей точки зрения, я делаю что-то не так?
                                                      0

                                                      Прямо жду не дождусь удовольствия повникать в содержание кода, где треть локальных переменных в camelCase, треть в PascalCase, а еще треть вообще КАПСОМ набрана. Потому что авторы этого были слишком талантливы, чтобы "задумываться о каждой мелочи".


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

                                                      +1

                                                      Неисполнение правил, которые мы обсуждаем, обычно упрощает code review. Например, то самое правило, которое было упомянуто в этой ветке (недопуск неиспользуемых переменных) ведет к ненужному раздуванию дифа.


                                                      Ну и да, на самом деле, даже если вообще никак за кодстайлом не следить, то ревью это сколько-нибудь существенно не усложняет. Так что "правила нужны ради упрощения ревью" — это не более чем распространенный миф. Кто-то сказал глупость — остальные бездумно за ним повторяют. обычное явление, впрочем.


                                                      А ты сам как думаешь?

                                                      Думаю, что лучше отключить.


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

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


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

                                                      Так в том и смысл, что не в отдельном. Наоборот — обычно как раз и надо эти правила нарушать (с неиспользуемыми переменными — точно, что за правило на счет статических методов — не уверен, уточните).

                                                        0
                                                        Это аналогия как раз в мою пользу. Я сам решаю прекрасно — чем и где мне есть, никакой линтер за этим не следит.

                                                        Ок. Дело твое. Точно так же ты можешь всегда сам решать — работать за деньги в команде, или работать забесплатно сам для себя :)

                                                          0
                                                          что за правило на счет статических методов

                                                          Шарповому линтеру по умолчанию не нравится, если ты делаешь экземплярный метод там где мог бы быть статический. Из-за немного более медленного вызова. К слову сказать, я не совсем с этим правилом согласен, но никогда не имел проблем из-за его соблюдения (кроме случаев подобных вышеупомянутому, хотя, на самом деле, и в том случае это просто результат не очень удачного уже имеющегося API).

                                                            0
                                                            Шарповому линтеру по умолчанию не нравится, если ты делаешь экземплярный метод там где мог бы быть статический.

                                                            100% же в линтере есть правило которое говорит, что статический метод нельзя вызывать через экземпляр, с-но когда у вас статический метод становится обычным (или наоборот), то надо менять все call-site. Ну а при обратном изменении (если статический метод становится обычным) менять вызовы придется в любом случае. Типичный пример вредного правила, которое ведет к раздуванию диффа.


                                                            но никогда не имел проблем из-за его соблюдения

                                                            Так постоянно встречается. Стоит чуть поменять метод (вызвать в нем this) — и привет рефакторингу с заменой всех вызовов.


                                                            собственно, вот она проблема линтера — он смотрит только на синтаксис. Линтер не понимает смысла кода (а потому не может отличить "синтаксически статический" метод, в котором просто в силу случайности нету this, от "семантически статического", который должен быть статическим по задумке), не имеет никаких предположений о том, как будет изменяться и т.п.
                                                            Линтер банально не обладает (и не может обладать) информацией, которая необходима для принятия решений о том, каким должен быть код. Поэтому и решать он ничего не может. Ну или может, но ошибается регулярно.
                                                            Если я не сделал метод статическим, значит, он по смыслу не должен быть статическим. Вне зависимости от мнения линтера по этому поводу. Мне лучше знать, чем линтеру :)


                                                            Точно так же ты можешь всегда сам решать — работать за деньги в команде

                                                            Неисполнение дебильных линт-рулзов только помогает работать в команде)
                                                            Меньше споров и внутреннего недовольства, выше производительность — а значит ниже стресс :)

                                                              0
                                                              когда у вас статический метод становится обычным (или наоборот), то надо менять все call-site.

                                                              Это да, поэтому мне самому это правило кажется немного спорным. Но, если честно, то не могу вспомнить случая, чтобы пришлось переделывать статику на нестатику или наоборот — это какое-то слишком уж сильное изменение семантики самого метода требуется. Считай то же самое, что перенос метода в другой класс, потому что статический метод это, фактически, не метод объекта класса Foo, а метод обьекта typeof(Foo). А, опять-таки, задумываться всякий раз делать ли мне метод статическим или экземплярным (когда можно и так и так) я не хочу — мне проще последовать совету линтера.


                                                              Меньше споров и внутреннего недовольства, выше производительность — а значит ниже стресс :)

                                                              Еще меньше споров, недовольства, и стресса будет если не работать вообще :))

                                                                0
                                                                Но, если честно, то не могу вспомнить случая, чтобы пришлось переделывать статику на нестатику или наоборот — это какое-то слишком уж сильное изменение семантики самого метода требуется.

                                                                Ну так метод семантически либо сразу статический, либо нет (это понятно, когда ты его создаешь). Но при этом он может не иметь this и быть по смыслу нестатическим (что регулярно происходит) — тогда линтер ругается, и мы делаем его статическим (хотя понимаем, что статическим он быть не должен). После чего this предсказуемо появляется — и надо переделывать обратно :)


                                                                А, опять-таки, задумываться всякий раз делать ли мне метод статическим или экземплярным (когда можно и так и так) я не хочу — мне проще последовать совету линтера

                                                                Но линтер не знает, должен быть метод статическим или нет — вот в чем штука.
                                                                Т.е. ваш подход — не думать и делать неправильно, оправдываясь тем, что "это посоветовал линтер".


                                                                Еще меньше споров, недовольства, и стресса будет если не работать вообще :))

                                                                Вы зачем-то работу (которая приносит пользу кастомерам, за что эти кастомеры платят деньги) равняете со следованием дебильным линт рулзам (которое никому ничего не приносит кроме потраченных нервов и уменьшения часового рейта).

                                                                  0
                                                                  Ну так метод семантически либо сразу статический, либо нет (это понятно, когда ты его создаешь). Но при этом он может не иметь this и быть по смыслу нестатическим (что регулярно происходит)

                                                                  Не буду сразу утверждать, что такое невозможно, но как-то сложно сразу такое придумать. Буду рад примеру.


                                                                  тогда линтер ругается, и мы делаем его статическим (хотя понимаем, что статическим он быть не должен).

                                                                  тогда линтер ругается, и мы метим конкретно этот метод атрибутом SuppressMessage с комментарием (Justification = "..."), почему мы этот метод все-таки сделали нестатическим.


                                                                  Т.е. ваш подход — не думать и делать неправильно, оправдываясь тем, что "это посоветовал линтер".

                                                                  Мой подход — думать над тем, над чем действительно надо мозгом думать, и сваливать по возможности все остальное на автоматизированные инструменты (в данном случае линтер).


                                                                  которое никому ничего не приносит кроме потраченных нервов и уменьшения часового рейта

                                                                  Какие нервы, какой рейт — у меня IDE сама все форматирует и отклонения от правил по шорткату исправляет, а сами правила с самого начала все лежат в Git (файл .editorconfig), поэтому общие для всех и не нуждаются в настройках.

                                                                    0
                                                                    Не буду сразу утверждать, что такое невозможно, но как-то сложно сразу такое придумать.

                                                                    Эм, ну практически любой метод без this)
                                                                    В смысле, на 1 реальный статический метод таких десяток приходится. правда тут конечно еще у вас особенности шарпа — в шарпе нельзя в топлевеле ф-и объявлять (ну, недавно вроде разрешили), а в js статические методы обычно просто выносятся из класса.


                                                                    тогда линтер ругается, и мы метим конкретно этот метод атрибутом SuppressMessage с комментарием (Justification = "..."), почему мы этот метод все-таки сделали нестатическим.

                                                                    Так а зачем это делать, если можно просто нестатические методы делать нестатическими, без SuppressMessage?


                                                                    Мой подход — думать над тем, над чем действительно надо мозгом думать, и сваливать по возможности все остальное на автоматизированные инструменты

                                                                    Нет, еще раз. Ваш подход — делать неправильно.
                                                                    Я тоже люблю использовать автоматизированные инструменты — но только в том случае, когда они работают правильно. А если они дают ошибочный результат, да еще и усложняют работу (в результате чего с автоматизацией трудозатраты выше, чем без них) — то нафига такая автоматизация нужна?


                                                                    Какие нервы, какой рейт — у меня IDE сама все форматирует и отклонения от правил по шорткату исправляет

                                                                    Далеко не все линт-рулзы исправляются. И, с-но, тем которые "больно" соблюдать как раз обычно не исправляются :)
                                                                    Ну и да — как ваш шорткат исправляет замену обычного метода на статик? Вместе с фиксом всех call-site и диффом на сотню строк?

                                                                      0
                                                                      Эм, ну практически любой метод без this)

                                                                      Ну а все-таки, какой-нибудь жизненный пример? Мне все равно сложно представить метод, который никак не связан с this, но при этом связан с конкретным экземпляром класса.


                                                                      Так а зачем это делать, если можно просто нестатические методы делать нестатическими, без SuppressMessage?

                                                                      А зачем вообще статические методы?


                                                                      Нет, еще раз. Ваш подход — делать неправильно.

                                                                      В чем неправильно-то? Использовать статические методы?


                                                                      Ну и да — как ваш шорткат исправляет замену обычного метода на статик?

                                                                      "Ctl + ." -> "Make static"


                                                                      Вместе с фиксом всех call-site

                                                                      Да, если в пределах солюшена.


                                                                      и диффом на сотню строк?

                                                                      По строке на каждый вызов плюс строка объявления самого метода. При обычном переименовании метода будет то же самое.

                                                                        0
                                                                        Мне все равно сложно представить метод, который никак не связан с this, но при этом связан с конкретным экземпляром класса.

                                                                        Так он сейчас не связан с this. А завтра оп — и будет. Ну банальный пример — у вас есть компонент, который выводит список чего-то, есть метод который генерит разметку для элемента списка. Если в списке нет контролов — и this не будет, т.к. все нужные данные есть в item, который передается в метод аргументом. Но вот завтра бах — и элемент списка надо уметь выделять, поэтому нужен this.setState.


                                                                        А зачем вообще статические методы?

                                                                        В жс, по сути — ни зачем, т.к. с тем же успехом можно просто объявить ф-и в отдельном модуле, разве что для декораторов это иногда полезно, т.к. статические члены, емнип, доступны в декораторе. В c# — ну, чтобы объявлять ф-и, которые "как бы не в классе", топлевел-объявлений-то там нет.


                                                                        В чем неправильно-то? Использовать статические методы?

                                                                        Нет, неправильно принимать решение о том, какой метод делать статическим, основываясь на советах линтера — который, условно говоря, в 50% не прав.


                                                                        "Ctl + ." -> "Make static"

                                                                        Ну т.е. автоматом это не фиксится, надо руками делать.


                                                                        По строке на каждый вызов плюс строка объявления самого метода.

                                                                        Так и зачем это нужно, если можно просто вырубить данное правило и не страдать?


                                                                        Смотрите, я вам говорю: "у нас проблема", вы в ответ: "ну, вот у нас есть такие решения, вроде и не сложные, а еще можно сделать так и так". Окей, но смысл в том, что проблемы вообще могло бы не быть, и тогда ее не пришлось бы решать — достаточно просто вырубить правило и все.


                                                                        ЗЫ: еще один кейс, кстати — если вам ваш статический метод захотелось перегрузить в подклассе. При этом тут ваще жопа — ведь исходный метод может быть вообще в другой сборке, к которой у вас нету доступа. И статический он там только из-за линтера, да). Отдельный вопрос — покажет ли линтер ошибку, если данный метод является частью реализации интерфейса? В случае тсовского линтера я прям уверен, что все равно покажет)

                                          0

                                          Ну конкретно в этой ситуации добавление исключения в линтер это нормально


                                          // this is a mock
                                          // eslint-disable-next-line no-unused-vars
                                          function fetchData(params) {
                                             return mockData;
                                          }

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

                                            0
                                            надо было заменить реализацию ф-и на заглушку

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

                                            Бесплатно могу рассказать руководству в каком направлении отправлять программистов, которые не умеют это делать…
                                              0

                                              это вы всем отделом не могли придумать или загуглить как игнорировать аргументы в обход линтера? Что за язык/линтер то хоть? Даже интересно гуглится ли решение за 5 минут

                                          0
                                          В Unix системах нет разницы между чтением файла из файловой системы, с девайса или потока. Эта строка в файлах нужна, чтобы узнать, что достигнут конец «данных» при чтении из входного потока — обычно это EOF. Когда ты открываешь стрим на APPEND, то он находит EOF, стирает и пишет с того места, в конце опять поставит EOF. Да, сейчас за тебя тебя много что делает современные тулы, но как быть со старыми?
                                            +1

                                            Ну так сейчас уже не CPM-овские времена с расстановкой 0x1A в неиспользуемом месте последнего сектора файла. Так что нет там никакого стирания EOF, просто к концу дописывают. Правда, если последняя строка не заканчивается переводом строки — то может сконкатенировать последнюю старую строку с первой новой.

                                          +5
                                          Другие люди будут привычны к другим правилам и их мозг всё равно будет взрываться. Тот же пример с CFO и FRC в статье.
                                          И даже сам через 2 года уже может будешь писать по другим стандартам (не потому что даже развиваешься, а потому что стандарты изменяются) и тоже старый код всё равно будет взрывать мозг.
                                          Поэтому согласны с автором статьи. Фанатизма должно быть по минимуму. Проблемы форматирования решаются бьютифайером, включая даже стандарты именования переменных (getJson vs getJSON). Оговаривать же надо только то, что не только не решается, но и приводит к проблемам (FRC vs CFO). Остальное — пусть каждый… как он хочет.

                                          Но всякие там правила вроде «не больше одного оператора в строке» вполне себе нужны, особенно если в команде есть джуны. Да и вообще, весьма хорошая практика иметь единый стиль оформления кода во всей компании, это просто удобно. Программистам же на самом деле это ничуть не мешает. Эти правила никак не усложняют написание кода, но впоследствии заметно упрощают его чтение и сопровождение.
                                          Такие мелочи просто приводить к единому стандарту в момент отправки кода.
                                          Нам, например, намного проще настроить у себя ИДЕшку на стандарт
                                          void main() {
                                          }

                                          и прикрутить бьютифайер к моменту отправки кода, чем каждый раз насиловать себя тратя лишние строки
                                          void main()
                                          {
                                          }

                                          и так далее по тексту.
                                          Писать надо так, как удобно. А вот коммититиь надо уже по стандарту.
                                            –30
                                            void main() {
                                            }
                                            я бы такой стиль запретил.
                                            Нет симметричности, не понятно где что начинается и заканчивается.

                                            Но в жаво-скрипте это не сработает: там куча конструкций, которые не получится использовать с фигурной скобкой в новой строке.
                                            И получается, что часть кода с новой строкой, а часть без новой. Тогда уж лучше пусть у всего кода открытая фигурная скобка будет в конце строки.
                                            Я смирился.
                                              +2

                                              жаль только большинство бьютифаеров еще фиг настроишь нормально… Например постоянная проблема — они умеют скобку либо всегда переносить, либо всегда оставлять. Переносить только если аргументы многострочные — до этого бьютифаеры не додумались (

                                                +1
                                                звучит как повод оставить issue на гитхабе вашего бьютифайера. Где можно проголосовать за эту фичу?
                                                0
                                                Правила переноса фигурных скобок важны.
                                                А вот важно ли, писать declare(strict_types=1) или declare(strict_types = 1)?
                                                  0
                                                  я уверен, что вы сходу даже не заметили разницу
                                                    +3
                                                    Важно! Так же важно, как и уважать читателей своего кода или поста на хабре.
                                                    Вроде накопипастил коммент 10 раз, мир не рухнул.
                                                    Страшно представить, как выглядит ваш код

                                                    image
                                                      0
                                                      божественный аргумент
                                                        0
                                                        Аргумент — это утверждение, приводимое в подтверждение другого утверждения.
                                                        Я не приводил аргументов — всего лишь сделал утверждение.
                                                        Это базовые поняти логики.
                                                        Программирование основано на логике.
                                                        Дальше развивать тему не считаю нужным.
                                                  +2

                                                  Суть поста 'Заставь дурака богу молиться...' Конечная цель нашей работы работающее приложение удовлетворяющее требованиям заказчика. Если правила упрощают эту задачу ОК. Есть правила усложняющие задачу (например англоязычное наименование всех без исключения сущностей).

                                                  +21
                                                  Я тоже поначалу не понимал, зачем нужны все эти правила — ведь и так вроде работает!
                                                  Сейчас, когда спустя 3 года, я правлю свой собственный старый код, я плачу кровавыми слезами и думаю — «ведь говорили же мне умные люди — делай нормально, почему я их не послушал?!»
                                                    0
                                                    Еще раз. Есть важные правила, есть не важные. Перенос фигурных скобок важен.

                                                    А вот важно ли, писать declare(strict_types=1) или declare(strict_types = 1)?
                                                    +10
                                                    Ты ревьювил чужой код? Такое ощущение, что нет. Когда тебе нужно быстро отревьювить мержреквест на пару сотен изменений, любой лишний пробел тормозит твое внимание. В этом случае куда важнее единый стиль у всех, чтобы взглянув на начало конструкции ты уже понимал, что она из себя представляет.
                                                      +9
                                                      Я десятилетиями ревьювю код. Почти во всех инструментах есть галочка «игнорировать пробелы».

                                                      Но дело вообще не в этом. Часто есть какие-то ситуации, когда код хочется сделать не по правилу. Но перфекционизм зачастую работает против здравого смысла.
                                                        +1

                                                        Где эта галочка в Гитлабе?

                                                          +1
                                                          В выпадашке справа от МР.
                                                            0

                                                            О, ишь ты, не видел. Спасибо за наводку.

                                                              0

                                                              Офигеть, спасибо. А то бывает после автоформатирования старых файлов 99% изменений приходится на пробелы в начале строки. ┬─┬ノ( º _ ºノ)

                                                        +15
                                                        Скажу почему в правила выносятся такие незначительные вещи — чтобы убрать разные холивары по поводу того, что «мне вот нравится два пробела ставить, а мне нравится три». В таких случаях просто выносится единое решение, заносится в список правил и в дальнейшем ссылаются на этот список.
                                                          +1

                                                          А лучше — само пусть делается

                                                            –1
                                                            Количество пробелов в начале строки — важное правило

                                                            А вот важно ли, писать declare(strict_types=1) или declare(strict_types = 1)?
                                                              0
                                                              А вот это уже и решает команда. С одной стороны, без пробелов строка выглядит компактнее. С другой стороны, пробелы помогают отделить знак, что может помочь найти ошибку, если она есть. Язык тут тоже имеет значение. Я предпочитаю ставить пробелы. Но этот подход должен быть однообразным во всем коде, чтобы было легче быстро читать исходники.
                                                                0
                                                                а насколько конкретно сложнее читать исходники, если жесткого правила не будет?
                                                                  0
                                                                  Зависит от конкретного человека. Для меня это будет примерно на 20% сложнее.
                                                            +4

                                                            Я надеюсь, вы понимаете, что PSR — это всего лишь стандарт, ему можно следовать, а можно и не следовать, но его нельзя написать "нестандартизированно", "неконкретно" и т.д. На него проще смотреть, как на формальное (именно поэтому MUST капсом, это из RFC пришло) описание конвенции по работе с кодом, принятой некоторым сообществом добровольно.


                                                            Если хотите, придумайте свой стандарт, в котором можно будет ставить лишний пробел. Уберите "неважные" правила из линтера и т.д. Получайте удовлетворение от решения задач и вместе с ними ворох лишних правок в коммите, когда кто-то нажмет Reformat Code в своей любимой IDE, настроенной на свой вкус. Так можно будет легко разобраться, что относится к задаче, а что — просто форматирование существующего кода. Еще будут веселые войны за положение скобочек, табы\пробелы и так далее, и эти войны будут скрывать реальные опечатки, косяки, баги.

                                                              0
                                                              Получайте удовлетворение от решения задач и вместе с ними ворох лишних правок в коммите, когда кто-то нажмет Reformat Code в своей любимой IDE, настроенной на свой вкус.

                                                              А она не должна быть настроена "на свой вкус". Везде, с чем приходилось сталкиваться правила любого линтера/форматтера легко пишутся в файл, добавляются в проект и сохраняются в общем репозитории.

                                                              +15

                                                              Правила оформления кода — это самый безобидный, простой и к тому же автоматизируемый способ поддерживать читабельность и чистоту. От нарушения каждого отдельного правила в каждом отдельном месте мозг не взорвется, но вот если каждый в проекте будет писать так, как ему вздумается, то взрыв как раз таки наступит очень скоро. И чтобы не тратить дни на бессмысленные споры типа табы или пробелы и придуман кодстайл.


                                                              У кого-то наступает выгорание от того, что линтер просит поменять порядок импортов? Толи ещё будет, когда к такому человеку придет бизнес с хард дедлайном!

                                                                0

                                                                Тут сразу вопрос, а чо ж он не поменяет, если знает, что именно надо поменять и где?

                                                                  0

                                                                  Линтер не поменяет, потому что поменяет форматер. Он для того и придуман, чтобы вообще о таких мелочах не думать и вручную не править

                                                                    0

                                                                    Ну дык вот он и есть, правильный подход. Я как увидел prettier и узнал про коммит-хуки, вообще расслабился

                                                                    0
                                                                    import IShouldBeThird from './third';
                                                                    import IShouldBeSecond from './second';
                                                                    
                                                                    import IShouldBeFourth from './fourth';
                                                                    import IShouldBeFirst from './first';
                                                                    

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

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

                                                                        0

                                                                        Но ведь с комментарием та же ерунда будет: линтер не знает почему этот комментарий был поставлен.

                                                                          0

                                                                          Но он хотя бы не удалит пустую строку

                                                                            0

                                                                            Да фиг с ней, с пустой-то строкой — она и правда не так важна. А комментарий, оторванный от прокомментированного блока — это ведь ещё хуже чем отсутствие комментария.

                                                                              0

                                                                              Действительно, сейчас проверил, если комментарий был на предыдущей строке, то он оторвется, а если на текущей, то норм. Получается, что нужно делать как-то так, если важно откомментировать конкретную строку:


                                                                              import component from './component'; // import this component

                                                                              Но если в целом, чувствительные к порядку импорты – это code smell, и лучше таким не увлекаться.

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

                                                                    При чем тут контроль версий?

                                                                      +1

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

                                                                        0
                                                                        Есть важные правила, а есть неважные.

                                                                        Важно ли, писать declare(strict_types=1) или declare(strict_types = 1)?

                                                                        Кроме того, все дифф-смотрелки умеют игнорировать пробелы
                                                                      0
                                                                      А кто запустит этот скриптик?
                                                                      +4
                                                                      varanio не переживайте, у вашего стиля написания миллионы последователей, поэтому у него есть даже специальное название — индусский код. У кого кровь из глаз течет, происходят прочие катастрофические события с разумом, а кто то благоденствует и спит спокойно :-)
                                                                        –4
                                                                        ну очень смешно
                                                                        +4
                                                                        Есть и еще одна причина выбирать максимально строгие правила — убрать правило можно всегда, а вот добавить после килотонн написанного кода уже бывает поздно.
                                                                        Да, бывают (псевдо)перфекционисты, которые следуют правилам без понимания, но это быстро исправляется вежливой беседой с правильно задаваемыми вопросами… ну или само как-то с опытом приходит.

                                                                        И добавлю еще пару выкриков в пустоту:
                                                                        — разделение проверки код стайла и самого код ревью — очень хорошая вещь.
                                                                        — мало договориться о правилах, нужно к каждому правилу дописывать его обоснование. Чтобы не было «какие-то законы, которые придуманы фиг пойми для чего»
                                                                          0
                                                                          > разделение проверки код стайла и самого код ревью — очень хорошая вещь.
                                                                          ну, код стайл проверяют линтеры обычно, еще до код ревью

                                                                          но и на код ревью может всплыть куча лишних писанных и не писанных правил
                                                                          +13

                                                                          Помнится, как на первом курсе жутко бомбило от начертательной геометрии. Ах, гостовый шрифт, дурацкие рамки, формат А3 и выше — какой чёрт вообще это придумал?!


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


                                                                          Итак, четвёртый год работы идёт. Электронные узлы для ракет воздух-воздух, комплекты модернизации для ЗРК, носимые портативные умные "устройства" — всё это уже обыденно и не вызывает животного страха перед бездной неизведанного. А самое главное — просветление. Просветление от дурости, что искусственно была помещена в голову наследниками лучшего в мире образования (с)


                                                                          Я понял, что свят тот человек, что придумал хотя бы гостовый шрифт (хотя я гоняю Isocpeur) да и вообще ЕСКД. Проект, блок, плата или даже чёртов кабель без оформленной нормально документации — это адская срань, головная боль и лучи поноса на его разработчика от того, кто столкнулся с его творением. Да, не каждому нравится заниматься творчеством будучи в рамках хотя бы правил оформления ЕСКД, но никому не будет нужен твой пусть трижды крутой труд, если он писан левой ногой, которую ещё во Вьетнаме пожгло напалмом. Я открываю док из 1960-х и вижу труды человека на одном языке со мною говорящего. И это круто. И пусть там совсем другие подходы к объекту разработки в принципе, ты сразу в теме.


                                                                          Не круто — открывать чей-либо труд и видеть там кривую-косую кучу смердящего самопала, ведь автору так виднее и красивее. Мнений, конечно, столько, сколько же и людей, потому моё мнение о статье выражается в одном слове после длинного интро. Нытьё.

                                                                            0

                                                                            Прочитайте еще раз статью. На мой взгляд стандарт должен быть (некоторые правила нужны), но максимально мягкий, затрагивающий только важные вещи для понимания. Т.е. буква О пишется как кружок, и должна быть читабельна. Но сколько градусов наклона — это дело десятое

                                                                              +8
                                                                              Т.е. буква О пишется как кружок, и должна быть читабельна. Но сколько градусов наклона — это дело десятое

                                                                              Как пишется нолик?


                                                                              Как пишется l (которая lowercase L), как пишется I (которая uppercase i), и как пишется 1 (которая единица)? Как задизайнить шрифт, чтобы эти глифы были максимально различимы?

                                                                                0

                                                                                Тест:
                                                                                'l' которая tolower('L')
                                                                                '|' которая 1/2 OR == '||'

                                                                                  +1
                                                                                  Отлично, вы описали важные правила. А есть неважные, например, угол наклона с точностью до градуса
                                                                                +4
                                                                                Я понял, что свят тот человек, что придумал хотя бы гостовый шрифт (хотя я гоняю Isocpeur)

                                                                                Вот видите, вам тоже не подошел гостовый шрифт, раз вы другой гоняете.

                                                                                  0

                                                                                  Главное что не два шрифта вперемешку

                                                                                +10
                                                                                1) В конце каждого файла должен быть перевод строки. А если не будет, то кто умрёт?
                                                                                2) Нельзя делать несколько statements на одной строке. Если я напишу $x = 1; $y = 1; $z = 1;, то читабельность ухудшится на 0.00001% и можно закрывать техотдел?
                                                                                Раздражает подобная демагогия. А если писать код всего приложения в одном файле, то на землю упадет астероид? А если парковаться на детской площадке, то то начнётся третья мировая война? А если после спортзала не принимать душ и ехать на общественном транспорте, то произойдет экологическая катастрофа?

                                                                                Не слишком страшно если кто-то написал несколько операторов в одной строке, или внезапно решил применить нетрадиционный для данного языка стиль. Плохо когда люди не признают своих ошибок, не исправляются, а пытаются как-то оправдать свой говнокод. Ещё хуже когда они знают, что каждая их строчка ухудшает читаемость на 0.00001% (по их мнению), но продолжают вредить проекту и своим коллегам.
                                                                                  –4

                                                                                  Чииайте внимательно. Про говнокод речи вообще не идет. Некоторые правила важны. Некоторые нет.


                                                                                  Ухудшение читабельности на 0.00001% не вредит ни проекту, ни коллегам

                                                                                    +6
                                                                                    Чииайте внимательно. Про говнокод речи вообще не идет.
                                                                                    Именно про говнокод тут и речь. Если код усложнен для восприятия без реальной на то необходимости, то этот код как минимум попахивает чем-то нехорошим.

                                                                                    Ухудшение читабельности на 0.00001% не вредит ни проекту, ни коллегам
                                                                                    А вы точно математик программист?

                                                                                    Некоторые правила важны. Некоторые нет
                                                                                    Дай бог вам побольше легаси за авторством тех, кто часто приходил к выводу о том что правила не важны :)
                                                                                      –1
                                                                                      Еще раз. Есть важные правила, а есть неважные.

                                                                                      Важно ли, писать declare(strict_types=1) или declare(strict_types = 1)?
                                                                                  +3

                                                                                  Абсолютно не согласна с автором. Считаю, что оформление единое оформление по стандартам крайне важно. Освоить стандарт несложно. Думать не надо: пиши код по правилам. Прикладывай творческие и умственные усилия там, где это действительно нужно. За нарушения стандартов я бы вообще розги бы выдавала.

                                                                                    +1

                                                                                    Добавлю. Я не программистка, но периодически приходится что-то по мелочи написать на незнакомом мне языке, например VB.Net или Lisp. Я всегда сразу ищу гайды, как принято на этом языке оформлять код, в каком стиле именовать переменные (например в .NET частенько ПолностьюПишутЗачемНужнаЭтаПеременная :)) ). Без этого мне некомфортно, приходится задумываться, а как бы лучше оформить. А когда есть правила: "делай раз, делай два", мне сразу гораздо легче программировать. Это экономит внимание и нервы.

                                                                                      –2
                                                                                      Есть важные правила, а есть неважные.

                                                                                      Важно ли, писать declare(strict_types=1) или declare(strict_types = 1)?

                                                                                      Кроме того, все дифф-смотрелки умеют игнорировать пробелы
                                                                                    –2

                                                                                    Есть некоторое количество простых правил, которые минимизируют количество ошибок, которые в принципе могут быть совершены — например, "окружать скобками любое, даже самое тривиальное выражение". Как я говорю, "Выражение без скобок — это как винтовая лестница без перил: могу ли я ее построить? Могу, без базара. Могу ли я подняться по ней? Да не проблема. Буду ли я чувствовать себя в безопасности, делая это? Нет, нет и ещё раз нет!!!"


                                                                                    Как вы понимаете

                                                                                    скобки предохранят от ситуации a = b * c, где c раскрывется (либо макросом, либо при невнимателным джуном при рефакторинге) в d + e, в результате чего получается выражение a = b * d + e, когда на самом деле нужно былоa = b * (d + e)

                                                                                      +1

                                                                                      Вы когда-нибудь задумывались над тем, что ситуаций, от которых можно бы "соломки подстелить" — в принципе бесконечное количество, и от всех вы не застрахуетесь?


                                                                                      Вы, конечно, можете сказать, что лучше быть застрахованным от какого-то числа ситуаций, чем от нуля ситуаций. Но встаёт вопрос о цене, которую вы за это платите. Вы же не тратите 100% своего времени на то, чтоб себя подстраховать? А собственно почему? Тратя всё ваше время вы застрахуетесь от большего количества ситуаций, чем если бы, например, тратили на это 99% времени и 1% на собственно разработку.


                                                                                      И вот когда вы это всё обдумаете, надеюсь, вам станет понятно, почему писать "вот это спасёт меня от вот таких проблем" — это, мягко говоря, пустая схоластика, если у вас нет конкретных данных о том, сколько ресурсов вы затратите на страховку (даже если это всего лишь "скобки расставить"), и сколько ущерба вам в среднем наносят подобные ситуации (без всякого "допустим, на проект придёт джун с IQ 30 и всё сломает").

                                                                                        +4

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

                                                                                        +4
                                                                                        скобки предохранят от ситуации a = b * c, где c раскрывется (либо макросом, либо при невнимателным джуном при рефакторинге)

                                                                                        в Сих нет такой проблемы — тупо c пишешь как макрос, только сразу правильно (скобки ВНУТРИ макроса) и все едет дальше на ура и без каких-либо проблем с раскрытием )
                                                                                        А вот писать a = b * (c) в коде — явная глупость.

                                                                                        +2

                                                                                        Меня так бесит написание интерфейса в джава коде на любой класс в вебсервисах. Я двумя руками за в фреймворках и библиотеках, но если в конкретном сервисе ровно одна имплементация — зачем его писать?! Кто-то при этом еще на I в SOLID ссылается, хотя это вообще о другом.
                                                                                        Адам Бин с Фаулером со мной солидарны в этом вопросе.

                                                                                          0
                                                                                          Так не пишите. Язык вроде не заставляет это делать.
                                                                                            +1

                                                                                            Язык-то не заставляет, а вот некоторые стайл-гайды...

                                                                                              0
                                                                                              Это повод их поправить. Заставлять людей писать болерплейт код везде это явно через чур.
                                                                                                0

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

                                                                                                  +1
                                                                                                  Это не перфекционизм. Это очень запущенный энтерпрайз.
                                                                                            0
                                                                                            У меня были некоторые случаи, когда я писал простенькие вещи (чисто для себя из эстетических соображений) «правильно», а не «как проще» и сам себе думал: «А на кой мне это делать? Почему бы не срезать угол, не нагородить костыль, не захардкодить, не пропустить проверку валидности аргументов...» А потом через месяц оказывалось что надо что-то срочно поменять и оказывалось, что то правильное решение, которое я считал избыточным, сейчас сэкономило мне кучу времени и сил.
                                                                                              0

                                                                                              Хм, а про что, по-твоему, I в SOLID? Как инвертировать зависимость без выноса интерфейса?

                                                                                                0

                                                                                                Разумеется, я имел ввиду D, а не I.

                                                                                                  +1
                                                                                                  Условный Spring уже довольно давно может внедрить не интерфейс, а инстанс класса, который он сам же и создаст. К инверсии зависимости ключевое слово interface имеет малое отношение — главное то, что зависимость создается не внутри объекта, а добавляется извне.

                                                                                                  Дальше я могу ошибаться в повествовании. Раньше такая роскошь была невозможна из-за специфики создания Proxy. А как прокси переписали на byte-buddy или подобную библиотеку, это ограничение сняли.
                                                                                                    0

                                                                                                    Ну, буква D в SOLID — это не DI, а DIP, она вообще не про внедрение зависимостей, а как раз про написание интерфейсов.


                                                                                                    Однако, ответ от этого не меняется: DIP предписывает выделять интерфейсы при формировании абстракций, но никак не заставляет формировать абстракции. Нет абстракции — не нужно и интерфейс выделять.

                                                                                                      0
                                                                                                      Кажется понял о чем вы.
                                                                                                      > DIP предписывает выделять интерфейсы при формировании абстракций, но никак не заставляет формировать абстракции.

                                                                                                      В этом вся и проблема. Сформирована у меня абстракция или нет — слишком абстрактный вопрос. Мы каждую минуты работы работаем с абстракцией — кодом. По такой логике интерфейс у меня должен быть на всё: репозитории, сервисы, контроллеры, абстракции структур данных и так далее.

                                                                                                      Идея SOLID была в получении поддерживаемого кода. И это только одна из теорий как получить поддерживаемый код. Layers, KISS, DRY, DDD, onion, hexagonal, FP,. Одни теории между собой компануются, другие нет.

                                                                                                      На практике же не всегда всё так гладко. Если в моём репозитории будет имплементация для условного Postgres, и в определенный момент придется съезжать на MongoDB, то скорее всего я просто перепишу внутренность репозитория. Если же переписать за один присест слишком сложно\рисковано — IDE прекрасно умеет выделить интерфейс. Для новой БД я уже его реализую. Ну или же менеджмент решит, что проект должен работать и на Постгре и на Монге — тоже путь через общий интерфейс.
                                                                                                      Другими словами, интерфейс мне нужен только в случаи нескольких имплементаций. Явное исключение из правил — фреймворки и библиотеки, где нужно оставить пользователю(программисту) возможность переопределить логику. Вот там интерфейсы и правда нужны.

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

                                                                                                        SOLID — это скорее про архитектуру, а не про код. И интерфейс на все не нужен, он нужен, в частности, там, где надо, собственно, инвертировать зависимость.
                                                                                                        Долго расписывать, советую почитать про это в первоисточнике — у Роберта Мартина в книге «Чистая архитектура», там в конце есть даже несколько страниц относительно архитектуры в типичных спринговых приложениях. Вообще интересная книжка, сам не так уж прям давно читал, получил удовольствие.

                                                                                                          0
                                                                                                          Я читал «Чистую архитектуру», и она произвела на меня впечатление как раз про код. Архитектура — о функциональных и особенно нефункциональных требованиях. Из них подбирается архитектура — микросервисы или монолит, будет кэш или не будет, будут сервисы с состоянием, или без, и какие БД нужны для всего этого добра. Всё для того, что бы обеспечить бизнес нужным им тулом.

                                                                                                          То, что описано у Роберта Мартина я бы назвал дизайном. Его виденье — оттянуть выбор вышенаписанного как можно дальше от старта написания кода. А при ошибке выбора как можно быстрее поправить. Поэтому он везде пишет о гибкости кода, и пропагандирует Agile. А про архитектуру ничего нет.

                                                                                                          У меня сложилось впечатление, что я читаю книгу о монолитах, как их писали в 2005-ом, может в банках 2010-ых.
                                                                                                            +1
                                                                                                            Я думаю, что, по меньшей мере, название этой книги говорит о чем она.
                                                                                                            И не совсем понял при чем там монолиты из 2005-тых? Описанные там принципы можно применять хоть в монолитах из 2005, хоть в микросервисах 2021.
                                                                                                        0

                                                                                                        Не совсем понял. «Выделение интерфейсов» и «формировании абстракций» — это же одно и то же.
                                                                                                        Зависимость должна быть в направлении модулей более верхних уровней. И оба типа модулей должны зависеть от абстракций: нижние — по иерархии наследования, верхние — по композиции.
                                                                                                        Тоесть в простейшем варианте, модуль с сервисами (который содержит бизнес логику и выше модуля доступа к данным) должен включать в себя интерфейсы доступа к данным и «зависеть» от них в классах сервисов. А модуль доступа к данным должен реализовывать интерфейсы из модуля сервисов. Таким образом получается инвертировать зависимость в сторону бизнес логики. Тоесть модуль доступа к данным знает про модуль сервисов, а модуль сервисов про модуль доступа к данным — уже нет. В ином случае, без вынесения интерфейсов, бизнес логика зависела бы от логики доступа к данным.

                                                                                                          0
                                                                                                          «Выделение интерфейсов» и «формировании абстракций» — это же одно и то же.

                                                                                                          Формарование абстракций гораздо шире, чем выделение интерфейсов. Вот абстракция кота:
                                                                                                          public record Cat(String name, int numberOfLives, String color) { }

                                                                                                          А вот простейшая абстракция кошелька:
                                                                                                          public class Wallet {
                                                                                                             public void withdraw(int n) { ... }
                                                                                                             public void deposit(int n) { ... }
                                                                                                          }
                                                                                                          


                                                                                                          Я под «выделением интерфейсов» говорил о том, что в этих двух примерах не нужно ключевое слово языка java interface. Мы об одном и том же говорим?
                                                                                                            0
                                                                                                            Не уверен, что понимаю, про что вы, но я писал об абстракциях именно в контексте DIP, где они противопоставляются деталям [реализации].
                                                                                                            0
                                                                                                            Что вы имеете ввиду под словом модуль? Модулем может быть класс, package/namespace с классами, third-party библиотека, отдельный сервис, или даже развернутый кластер в кубере.

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

                                                                                                              >>Я предположу, вы хотели сказать, что зависимости должны быть в отношении слоёв приложения. Где внутренний слой доменная модель, которая ни от чего не зависит.
                                                                                                              Да, это именно из той самой книжки Мартина. Но нет, я имел ввиду именно то, что написал. Два модуля: с бизнес-логикой и с логикой доступа к данным. Для этого примера все равно как организована сама бизнес логика, скажу даже еще более страшную вещь: не обязательно должна быть модель домена.
                                                                                                              –1
                                                                                                              В ином случае, без вынесения интерфейсов, бизнес логика зависела бы от логики доступа к данным.

                                                                                                              Очень спорное заявление. Есть две книжки по DDD, в которых доступ к данным закрыт абстракцией Repository. А уж какая там реализация доступа — ну как напишут. На то оно и сокрытие) И реализация есть этого подхода — Spring Data.
                                                                                                              А основано всё еще на Фаулере 2002-го года. Только в них называется «слои», а интерфейс вынесен для ускорения тестирования.
                                                                                                                0
                                                                                                                В каком смысле спорное заявление? Перефразирую немного: без вынесения интерфейсов, в классах с бизнес-логикой пришлось бы импортировать классы из модуля с доступом к данным, что означало бы, что бизнес логика зависела бы от логики доступа к данным.
                                                                                                                И тут совершенно не важно, используется Repository или нет.
                                                                                                            0
                                                                                                            К инверсии зависимости ключевое слово interface имеет малое отношение

                                                                                                            Ты путаешь "инверсию зависимости" (dependency inversion) и "внедрение зависимости" (dependency injection).

                                                                                                              0
                                                                                                              Согласен, я не прав. Перечитал матчасть.
                                                                                                      +5

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

                                                                                                        +3
                                                                                                        Верно. Первое правило как раз на эту тему: отсутствие перевода строки в конце файла, это лишний шум при diff'ах. Второе правило ускоряет анализ изменений.
                                                                                                        В команде разработчиков FreeBSD, был легендарный человек Bruce Evans aka bde, который линтил почти все коммиты в ядро — пару раз мне прилетало от него за какую-то мелочь, и так же как автор, пытался с ним спорить. И оба раза был вынужден признать, что да, даже эти мелочи важны для проекта, над которым работают десятки людей.
                                                                                                        Причем, на то время был лишь один разработчик, который бурно огрызался на каждое замечание от bde, но это просто особенность характера, т.к. в публичной дискуссии сразу было видно, что все его доводы о необходимости нарушения style(3) не больше, чем детский лепет, по сравнению с железобетонными аргументами bde.
                                                                                                          +1

                                                                                                          Так может, просто заменить почти всю ту толстую пачку правил, которые это обеспечивают, на ровно одно правило — в коммите можно править чужой стиль только в том случае, если в этом коммите правится только стиль, и в описании коммита явно написано, что это правка стиля?
                                                                                                          И, кстати, если кто-то бездумно жмет "Reformat code" в IDE и потом коммитит весь получившийся трэш ради тщательно спрятанной в нем одной строчки содержательных изменений — он должен перестать это делать, потому что это сильно мешает коллегам.

                                                                                                            0
                                                                                                            в коммите можно править чужой стиль только в том случае, если в этом коммите правится только стиль, и в описании коммита явно написано, что это правка стиля?

                                                                                                            Вы с легаси кодом не работали? Делаешь тикет. И понимаешь что надо поменять пару строчек вот в этом файлике который лет 5 никто не трогал.
                                                                                                            А он не закомитится с несоблюденим стайлгайда. Надо или приседать с ветками черрипиками и прочим или просто написать комментарий к реально измененным местам. Прямо в комменты в вашей системе код ревью.
                                                                                                            Если там несколько строк, то менять все сразу всем удобнее и быстрее.
                                                                                                              0
                                                                                                              А он не закомитится с несоблюденим стайлгайда.

                                                                                                              Это условие несовместимо с наличием нарушающего стайлгайд легаси.


                                                                                                              На практике нет ничего проще же: делается два коммита, в первом правится стиль, во втором содержание. Если таких файлов много — fixup commit и интерактивный rebase в режиме autosquash в помощь, никаких приседаний не нужно.

                                                                                                                –1
                                                                                                                Это условие несовместимо с наличием нарушающего стайлгайд легаси.

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

                                                                                                                На практике нет ничего проще же: делается два коммита, в первом правится стиль, во втором содержание. Если таких файлов много — fixup commit и интерактивный rebase в режиме autosquash в помощь, никаких приседаний не нужно.

                                                                                                                По сравнению не делать ничего это все равно приседания. А еще бывают обязательные код ревью. Это еще и время тогда занимает.

                                                                                                                Я именно про простейшие случаи. Когда в файле где правится стиль правится исправления минимальны. А не когда весь коммит это вперемешку стиль и куча кода. Тогда да по очереди. Оно того стоит.
                                                                                                                  0
                                                                                                                  По сравнению не делать ничего это все равно приседания. А еще бывают обязательные код ревью. Это еще и время тогда занимает.

                                                                                                                  Да ладно, один мой коллега на одной прошлой работе проблему с обязательными код ревью решил изящно. Он просто assign'ил сам себя ревьювером, сам себе писал LGTM, сам мержил.


                                                                                                                  Начальство его ох как любило.

                                                                                                                    0
                                                                                                                    Запретить self assign техническими способами. Неудобно, но сработает.
                                                                                                                    Как привыкнет через полгодика снова разрешить. Это иногда надо для всяких технических коммитов.
                                                                                                                      0

                                                                                                                      А кто и зачем будет там что-то запрещать? Продуктивность (в LOC'ах, по крайней мере) у него была сверхвысокая. А что результат всё время падает — ну так предметная область сложная. А что после его ухода через пять лет всё выкинули и переписали с нуля, потому что кроме него никто не мог (и не хотел) это всё поддерживать — ну так кто ж знал, да и это через пять лет было.

                                                                                                                        0
                                                                                                                        Вы же сами написали зачем. Если это не гений мирового уровня, то обоснование отличное.
                                                                                                                        Раз его код постоянно падал и переписать оказалось проще чем поддерживать, на гения он не тянет.

                                                                                                                        Код звезд в котором я копался был достаточно хорош. Читается и правится без особых проблем. И не падет, по крайней мере постоянно.
                                                                                                                          0

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

                                                                                                                  0
                                                                                                                  Это условие несовместимо с наличием нарушающего стайлгайд легаси.

                                                                                                                  Пфф, запросто — стайлгайд ввели после последнейй правки этого файла.


                                                                                                                  Разбивать по коммитам смысла нет никакого — в мерж-реквесте все правки всё-равно будут вместе. Формат надо править в отдельной ветке, до того, как править реальные правки.

                                                                                                                    0
                                                                                                                    Пфф, запросто — стайлгайд ввели после последнейй правки этого файла.

                                                                                                                    Если его ввели просто на словах — ну и пофиг на него. Если стоит автоформатер или даже проверка при коммите — значит, надо взять автоформатер и прогнать через него весь проект 1 раз.


                                                                                                                    Разбивать по коммитам смысла нет никакого — в мерж-реквесте все правки всё-равно будут вместе.

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

                                                                                                                      –1
                                                                                                                      Если его ввели просто на словах — ну и пофиг на него. Если стоит автоформатер или даже проверка при коммите — значит, надо взять автоформатер и прогнать через него весь проект 1 раз.

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

                                                                                                                      Автоформатер по всему коду прогонять страшно. Там такое бывает… Лучше не трогать от греха.

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

                                                                                                                      Можно, но неудобно. Написал код — поправил стиль — написал код — дописал тесты — переписал код — а тут еще на стиль ругается поправил.
                                                                                                                      За коммитами в ветке никто не следит. Там обычно мусор.
                                                                                                                      Все равно все сквошится при мердже.

                                                                                                                      Руками сделать любую историю коммитов потом можно. Но это опять приседания просто так.
                                                                                                                  0

                                                                                                                  Вот именно поэтому я и не люблю энфорсинг чего угодно на уровне коммит-хуков, и поэтому же не люблю непрошенные или слишком легко делаемые "reformat code". Если это небольшая локальная правка в легаси-файле — то надо просто поправить, придерживаясь стиля, принятого в этом конкретном файле. Даже если это неудобно и нужно руками в нужных местах пробелы добавлять. А не выдавать коммит, в котором мешанина.

                                                                                                                  0

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


                                                                                                                  В итоге подключили prettier, сделали один большой супер-коммит с переформатированием всего и зажили нормально

                                                                                                                  0
                                                                                                                  Есть важные правила, а есть неважные.

                                                                                                                  Важно ли, писать declare(strict_types=1) или declare(strict_types = 1)?

                                                                                                                  Кроме того, все дифф-смотрелки умеют игнорировать пробелы
                                                                                                                  +5

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


                                                                                                                  • некоторые скрипты, грепающие это безобразие
                                                                                                                    В конце текстового файла действительно лучше оставлять новую строку
                                                                                                                    +2
                                                                                                                    Автор упустил из виду самый важный, на мой взгляд, вопрос — Вам одному мешает этот якобы чрезмерный перфекционизм или он раздражает всю команду? Если второе, то что мешает собраться командой, потратить полчаса и пересмотреть стандарты? Если первое — то тот факт, что так думаете только вы, то, возможно, не стоит навязывать это мнение коллегам. Ведь объективных аргументов в Вашей статье, по сути, нет…
                                                                                                                    Из личного опыта — проработав почти 10 лет в компаниях Amazon и Google, могу сказать, что более драконовских и детальных кодинг стайлов, чем в этих компаниях, я не встречал. Но лично для меня принять это никогда не было проблемой, т.к. я очень люблю кодинг стандарты. Какие-то детали в них мне не нравились, но это адекватная плата за единообразие, без которого половина проектов могла бы загнуться — текучка невероятная, люди постоянно переходят из команды в команду, над проектом может работать по 10+ человек, у всех свои в голове заморочки как надо правильно. В этой ситуации стандарты — это спасение, если надо что-то быстро найти в огромном коде.
                                                                                                                    Будь моя воля, я бы еще чуть стандартизировал не только код но и кодинг паттерны, ибо есть любители навертеть не пойми что и ссылаться на какой-то паттерн из интернета — будто бы факт наличия статьи в нете (или просто даже поста на StackOverflow) автоматически доказывает правильность.
                                                                                                                    Мне кажется гораздо продуктивнее ослабить требования к процессу (лично я не люблю SCRUM) и максимально ужесточить требования к кодингу — но это, наверное, тема для отдельной дискуссии.
                                                                                                                      0

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


                                                                                                                      В современных IDE, например Phpstorm, можно настроить автоформатирование при сохранении.
                                                                                                                      У меня так уже несколько лет работает, как и у половины коллег. Поэтому специально придерживаться стандартов не нужно — IDE это делает за программиста.

                                                                                                                        +3

                                                                                                                        Ситуация, которая описана в статье — частный случай общей проблемы с любыми правилами вообще.


                                                                                                                        Правила должны иметь практический смысл.


                                                                                                                        Если они его не имеют, потеряли (полностью или частично) или никогда не имели, начинаются самые разные частные проблемы.
                                                                                                                        Например, слишком универсальные и слишком строгие правила (как в самом первом примере статьи) порождают нигилизм в отношении обоснованных правил и подрыв авторитета руководства, потому что все знают, что правило создано вместо того, чтобы разобраться с отдельным человеком, потому к ним оно применяется незаслуженно. Далее, у сотрудников возникает вывод, что руководство — самодуры, которым больше нечем заняться, и которые не знают о реальных проблемах, а также — считают, что все сотрудники — безответственные. (Это реальная ситуация из моей практики.)


                                                                                                                        Впрочем, в создании хороших правил есть много нюансов. Скажем, правила, которые созданы ради унификации, могут быть и хороши, и плохи. Хороши, когда унификация, в свою очередь, имеет практический смысл. Плохи — когда это унификация ради самой себя, а возможные негативные последствия от нее полностью игнорируются. У меня был случай, когда один молодой активный бригадир увидел стойку для инструментов, где было подписано место для одного единственного специального инструмента, и ради унификации подписал все остальные места. Итог — особая важность возврата того самого инструмента на одно и то же место потерялась, и все стали ставить всё куда попало.


                                                                                                                        Создание разумных правил — сложная задача, об этом можно много написать.

                                                                                                                          +2

                                                                                                                          Код стайл не для того чтобы писать код, а для того, чтобы его потом читать. Ведь в любом сколь либо отдаленно серьезном проекте код читается во много раз больше, чем пишется. И когда почитаешь много кода, от разных людей, от студентов до аксакалов, понимаешь, насколько важна консистентность стиля (не чтобы он был каким-то определенным, а одинаковым), насколько важно чтобы в вашем MVC model была именно моделью, чтобы названия были говорящими, ну и все остальное.


                                                                                                                          Что касается общего линтера на весь язык — да что может быть лучше? Все постепенно привыкают к единообразию, а следовать стилю — один хоткей в IDE.

                                                                                                                            +1

                                                                                                                            Главная нужность правил в линтерах — когнитивная предсказуемость и соответственно непонижение скорости чтения кода. Думать о нужности правил здесь бессмысленно. Главное что они есть какие-то — табы/пробелы, пофигу. Главное, что у всех едино.


                                                                                                                            Дисциплина сделала из банды армию.

                                                                                                                              –7

                                                                                                                              Когда в проекте начинают прикручивать линтер и всякие там подобные штуки — я точно знаю, пора искать другой проект :)


                                                                                                                              Это значит пошла работа под "среднего программиста", которому некогда думать про код, ему писать надо его. Обычно это сопровождается повышением удельного количества менеджеров на программисткую душу.


                                                                                                                              Короче говоря, когда коту делать нечего — он яйца лижет.

                                                                                                                                +3
                                                                                                                                Когда в проекте начинают прикручивать линтер и всякие там подобные штуки — я точно знаю, пора искать другой проект :)


                                                                                                                                И много проектов удалось найти?

                                                                                                                                Нет, я не буду говорить о пробелах вместо табуляций и прочей ерунде. И не буду спорить про «правильное/неправильное форматирование». Но когда в процессе CI первым делом прикручивается проверка на coding style, потом code review, потом функциональные тесты (если не требуется покрытие unit), потом разворачивание в песочнице, и только потом передача в тестлаб — это правильно.

                                                                                                                                А если этого нет, то я пойду твоим путём — пойду искать новое место работы.
                                                                                                                                  –4
                                                                                                                                  линтеры нужны, вопрос в том, что в них проверяется, не ерунда ли это
                                                                                                                                    0

                                                                                                                                    Это был сарказм, конечно.


                                                                                                                                    Но я видел много людей кого заботили пайплайны, но гораздо меньше заботило — а стоит ли здравый смысл за этими пайплайнами.


                                                                                                                                    Так, в одном проекте линтером был запрещен постфиксный ++. Потому что есть программисты, которые не понимают постфиксной сути и ошибаются.


                                                                                                                                    Вместо обучения программистов был забанен оператор...


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

                                                                                                                                  +5
                                                                                                                                  Дома, когда ты пилишь свой pet-проект, ты используешь язык тот, какой хочешь, форматируешь код, как хочешь, структурируешь код, как хочешь.

                                                                                                                                  При этом я всё равно следую некоторым правилам, имею общий стиль форматирования, слежу за грамотной структурой, и так далее. Да, вы не надеваете галстук, но вы надеваете трусы, чистите зубы с утра и умываетесь.


                                                                                                                                  Дофаминовый цикл "сделал задачу — получил удовлетворение" нарушен. Сделал задачу — получи звиздюлей от линтера и коллег на код ревью.

                                                                                                                                  Это ещё что! Мне до выполнения задачи тайпчекер регулярно даёт звиздюлей. И это офигенно, потому что задачи, считайте, не приходится отлаживать.


                                                                                                                                  Мы ругаем бешеный принтер, ограничивающий свободу, но сами часто действуем по принципу "запретить и не пущать".

                                                                                                                                  И это тоже офигенно. Чем больше возможностей мне даёт язык по запрету нежелательного, тем лучше. Мне приятнее писать на достаточно сильно типизированном хаскеле или вообще адово типизированной агде вместо нетипизированного JS или Python. На последних, собственно, я вообще писать не могу, и моя продуктивность падает до нуля при размере кодовой базы уже в 50-100 строк.


                                                                                                                                  Если назвать переменную "FRC", то новичку будет непонятно, что это за хрень. В документации по продукту термин везде по русски, ЦФО.

                                                                                                                                  Мне как новичку «FRC» и «ЦФО» примерно одинаково непонятны.

                                                                                                                                    0

                                                                                                                                    Я бы опасался сидеть рядом с человеком, который понимает, что надо чистить зубы и одеваться, но самому ему лень это все помнить, поэтому он нанял еще парочку людей, один из которых постоянно за ним прибирает и причесывает, а второй — следит что первый все правильно сделал :)


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

                                                                                                                                    +1
                                                                                                                                    Любой инструмент уместен в своём классе задач.

                                                                                                                                    Не кажутся нужными какие-то правила в линтере? Ну так обсудите в рамках компании/проекта/команды и поменяйте набор правил, в чем сложность? Вроде нынче любой линтер позволяет контролировать только то, что хочется. При этом вполне может оказаться, что в ходе обсуждения Вы осознаете, зачем эти правила были введены.

                                                                                                                                    Это кстати частая проблема принятых когда-то решений, что решение осталось, а история, как, кем и зачем оно было принято — нет. У той же Atlassian есть прекрасная традиция в культуре компании — все принятые решения фиксируются не только в части «что решили», но и «кто, зачем, какие факторы были учтены» и т.д.
                                                                                                                                      –1
                                                                                                                                      Маленькие дети читают только печатные буквы и с расставленными знаками ударения.
                                                                                                                                      Потом учатся писать и читать рукописный текст.
                                                                                                                                      Потом поэты и писатели начинают играть с правописанием и разметкой текста.
                                                                                                                                      А потом рукописи и черновики ценятся больше, чем печатный прилизанный текст :)
                                                                                                                                        0
                                                                                                                                        Пример с одиночным перформингом некорректный.
                                                                                                                                        Ты пишешь огнем не потому, что пишешь как нравится, а потому, что пишешь из абстракций в голове.
                                                                                                                                        А все правила код стиля и оформления, как и архитектура, паттерны и прочее, не нужны чтобы писать, они нужны, чтобы читать. Причем, обычно не тебе.
                                                                                                                                        Впрочем соглашусь в том, что это не значимый вопрос. Скорее важно, как большинство в команде привыкло, чем конкретный стандарт. Но договориться стоит.
                                                                                                                                          0
                                                                                                                                          а по поводу пересмотра правил… это действительно необходимо, но возможно только в том случае, если можно понять почему они введены. если нет какой то доки или описания, приходится соблюдать потому что понятия не имеешь что отвалится, если будет по другому.

                                                                                                                                          это про правила в целом. а вопрос про форматирование решается автолинтером, который правит код по сочетанию клавиш.
                                                                                                                                            0

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


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

                                                                                                                                              –1
                                                                                                                                              В пет-проджекте вы чаще пишите код, чем читаете. В практически любом командном проекте — наоборот.

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

                                                                                                                                                  Лично я весь "креатив" в оформлении направляю на то, чтобы код было удобнее читать (в том числе мне самому хоть через полчаса, хоть через полгода). И да, порой стайл-гайды этому нехило мешают.

                                                                                                                                                    0
                                                                                                                                                    вам мешает неудачно выбранный конкретный стайл-гайд или сам факт наличия какого-то стайл-гайда?
                                                                                                                                                      0

                                                                                                                                                      Как правило, мешает конкретный. Думаю, если я потрачу достаточно времени, я сумею записать алгоритм того как я оформляю код в виде стайл-гайда (и с этого момента этот гайд начнёт мешать кому-то ещё).

                                                                                                                                                        0
                                                                                                                                                        да, понимаю, о чём вы. я думаю, это издержки любой командной работы (и тоже важное отличие от пет-проджектов) — кое-где приходится идти на компромиссы, что само по себе не всегда приятно. вряд ли существует стайл-гайд (или любые другие соглашения), который на 100% совпадал бы со встроенными хотелками всех членов команды. но тут, если вы понимаете, ради чего вы идёте на эти уступки, то вам ок. а если не понимаете — то пишете пост на хабр типа того, который мы с вами комментируем.
                                                                                                                                                          0
                                                                                                                                                          другими словами, автор гово