Член команды категорически против форматирования кода

Я руководитель небольшой команды разработчиков (5 инженеров, включая меня).

Несколько месяцев назад по предложению другого коллеги мы ввели обязательное форматирование кода в базу кода, для нашего основного проекта. Наш проект написан на Python, а инструмент форматирования black(наверное, не актуален).

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

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

Как бы вы поступили в такой ситуации?

Что бы вы ответили на «форматирование кода — полная ерунда» , «это как цвета, кому-то нравится красный, кому-то синий, вот и все» , «оно ограничивает мою свободу» , «оно усложняет чтение кода, не добавляя никакой ценности» и т. д. ?

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
Возможно, вы захотите отредактировать , чтобы уточнить, что на самом деле нет трудоемких проблем с редактированием кода или регистрацией (у меня есть проблемы с форматированием, которое не может быть разумно установлено по умолчанию в моей среде IDE - я не очень люблю добавлять пробелы вручную, чтобы сделать средство форматирования/проверки стиля счастливым). Четко ответы показывают, что вы смотрите на межличностную проблему, а не на настоящую боль, которую вы представили.
Одна вещь, которая может помочь нам немного лучше понять вашу ситуацию, это то, обсуждали ли вы это решение со своей командой до того, как оно было реализовано. Когда вы говорите «мы ввели обязательное форматирование кода», вы имеете в виду «мы, команда, решили...» или «как руководитель группы, я решил, что наша команда будет...»? Были ли у вас конструктивные обсуждения с вашей командой перед внедрением переформатирования, если да, то высказывал ли тогда ваш «ведущий разработчик» какие-либо возражения? Если да, то были ли выслушаны их возражения? Или они сделали пулл в один прекрасный день только для того, чтобы обнаружить, что все было переформатировано под них?
Интересно узнать, что именно подразумевается под форматированием , насколько детальное форматирование? Хотя абсолютно полезно иметь одинаковые отступы, положение фигурных скобок и т.п., это абсолютная ерунда и совершенно бесполезно навязывать точное количество пустых строк во всех мыслимых ситуациях, таких как комментарии или функции, а также в середине. функций. Для меня быть правым или неправым сильно зависит от таких деталей. Не могли бы вы добавить примеры?
@puck OP использует черный, что является очень разумным способом форматирования кода. Сотрудник ведет себя ужасно неразумно, жалуясь на такой стиль.
Будет ли на самом деле согласование стиля кода, а затем создание инструмента, который будет вариантом? Возможно, начнем с черного по умолчанию, а затем обсудим, нужны ли какие-либо изменения (поскольку использование того же, что и все остальные, обычно является хорошей идеей)?
@puck, в частности, гарантирует, что вы не увидите коммиты базилионов строк только потому, что кто-то запустил другой форматировщик для всего проекта и считает себя вправе высказать свое мнение об этом.

Ответы (26)

Честно говоря, моя реакция была бы следующей:

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

А если бы я хотел вступить в дискуссию?

"форматирование кода - полная ерунда"

Это не очень конструктивный отзыв, можно поконкретнее?

"это как цвета, кому-то нравится красный, кому-то синий, вот и все"

Конечно, но стандартизация этих «цветов» очень полезна, и нам пришлось выбрать один!

"это уменьшает мою свободу"

Как и согласие писать код на том же языке и версии этого языка, но можете ли вы представить себе хаос, если бы мы этого не сделали?

«это делает код более сложным для чтения без добавления ценности»

Это не правда. Через некоторое время после прочтения кода в этом формате его вообще не будет сложнее читать — на самом деле его будет проще читать (добавленная ценность), потому что вам нужно будет изучить только один стиль для всего проекта. Кроме того, это означает, что PR-менеджерам намного удобнее читать различия, мы можем подключать других разработчиков и быстрее настраивать их, а разработчики не будут зацикливаться на том, какое форматирование может выглядеть немного красивее в данной ситуации.

Чтобы было ясно, если его отзыв был конструктивным , скажем о формате: «Я не думаю, что Блэк полезен для нас по причинам x, y и z, поскольку большая часть нашего кода следует стилю кодирования bc, с которым Блэк плохо справляется, рассматривали ли вы (другой инструмент) вместо этого», то это совсем другой сценарий. Именно тогда вы должны приложить все усилия, чтобы участвовать в обсуждении, чтобы подтвердить его опасения, и работать с ним над их решением.

but I'm afraid that if you want to stay in this teamВ моей голове я мог бы подумать об этом, но я бы определенно не сказал об этом таким образом, по крайней мере, в начале. Этот парень кажется человеком, который может быстро обостриться, и эта формулировка, вероятно, заставит его обостриться быстрее. Я бы сказал что-то вроде: «Я понимаю, что это не твое личное предпочтение, но я должен был сделать выбор за команду, и это все». Я думаю, что общая цель состоит в том, чтобы помочь всем понять преимущества и присоединиться к группе. Если он продолжит бунтовать, то вы заговорите.
@JeffC Да, это справедливо. Я имел в виду , что это не подлежит обсуждению, пока он там работает, но, читая это, это звучит гораздо более конфронтационно, чем я предполагал...!
but as a team we've decided that we're using Black as our mandatory code formatting tool, ОП никогда не заявлял, что это было командное решение.
@Akavall «по предложению другого коллеги, которого мы представили ...» Акцент мой, и это звучит так, как будто это командное решение для меня. Если это не так, то (я думаю, очевидно) просто отбросьте бит «как команда». Остальная часть ответа остается в силе.
«Мы ввели» не означает, что решение о введении было принято командой, могло быть, но не должно было быть. Я был бы осторожен, заявляя, что что-то было решением команды, когда на самом деле это было не так.
@Akavall Я думаю, что любой предлагаемый ответ должен быть изменен в соответствии с ситуацией. Как я уже сказал выше, если это не командное решение, отбросьте фразу «как команда». Это должно быть довольно очевидно, как и изменение имени указанного коллеги, если это не «Боб»!
Что касается форматирования кода, оно полностью зависит от того, как именно он переформатируется. Например, если он автоматически меняет определения функций обратно в стиле K&R, он может быть прав. Или делать ужасные вещи, чтобы уложиться в 80-символьные ограничения, или усекать имена переменных. Попытка найти то, что ему не нравится в стандартизированном формате, может быть полезно для ОП.
@ Грэм Абсолютно. Если его отзыв был «это автоматически изменяет определения функций обратно на K&R, и это бесполезно», то это конструктивная критика, и вам следует поработать с ним, чтобы увидеть, есть ли обходной путь или, возможно, другой инструмент, который лучше подходит для этой задачи. . Но это далеко от аргументов «это фигня и ограничивает мою свободу», которые мы видим в ОП.
@berry120 Как человек, который очень долго играл по правилам MISRA, я полностью согласен. Свобода в кодировании обычно переоценивается. Мне нравится иметь предохранители на вещах, которые могут выстрелить мне в ногу. :)
Я решил принять этот ответ - я могу принять только один, даже если есть так много других хороших моментов. Решение об автоматическом обязательном форматировании кода было принято с одобрения других членов команды (за исключением одного, тогда...). Хотя другие моложе. Я использовал слово «ведущий разработчик», потому что он имеет общее представление о проекте и является старшим, но я также кодер в команде... Конечно, моя двойная роль иногда усложняет ситуацию. Спасибо за помощь, ребята !
Некоторые комментарии, относящиеся к Black, могут заключаться в том, что мне не нравится, как он форматирует все — принудительно заключает в двойные кавычки, но выбирает что угодно — но я откажусь от этого для согласованности . Почти полное отсутствие конфигурируемости означает, что у вас не может быть всех этих крошечных ссор из-за того или иного, это либо бери, либо оставляй.
"Мы должны были выбрать один!" просто заставляет меня задуматься : «Я дальтоник, и вы стандартизировали цвета, которые затрудняют чтение, почему мои потребности не были приняты во внимание? Почему со мной не посоветовались?» . Этот ответ направлен на то, чтобы заставить непокорного разработчика подчиниться, сделав и без того враждебную среду еще более враждебной. Быть менеджером — это не держать удары плетью до тех пор, пока моральный дух не улучшится, а снимать барьеры, которые мешают людям реализовать свой потенциал. См. Программное обеспечение для людей .

Как бы вы поступили в такой ситуации?

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

"форматирование кода - это полный б***ь хит"

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

"это как цвета, кому-то нравится красный, кому-то синий, вот и все"

Как ваш менеджер , я люблю красный цвет, смиритесь с этим.

"это уменьшает мою свободу"

Форматирование кода не влияет на свободу создания элегантного решения. Я звоню в BS по этому поводу, и вы тоже должны.

«это делает код более сложным для чтения без добавления ценности»

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

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

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
@Eyal - Иногда быть задней частью осла - единственный способ поговорить с сотрудником, который является целым ослом. (Иными словами, осел за осла).
Для меня, если нет конкретных критических замечаний по поводу стиля форматирования, который не нравится сотруднику (табуляции и пробелы, количество пробелов в табуляции [что, кстати, на самом деле является проблемой только тогда, когда пробелы выбираются вместо табуляции ], размещение скобок, практика продолжения строки и т. д.), то они просто сложны ради сложности. ОП не указал, что у сотрудника есть какие-либо конкретные критические замечания по поводу текущего инструмента, а только форматирование в целом.
Самоуверенный человек чрезвычайно полезен после обращения и может стать бесполезным, если его принудить . Бывают случаи, когда последнее необходимо, но это отличный способ разрушить продуктивность и мотивацию. Первое обычно более конструктивно — хорошее вложение для команды и менеджера в среднесрочной перспективе, если все сделано правильно. Можно оттолкнуть кого-то, кого можно было бы обратить при должной ловкости и понимании , и кто был бы мощным активом. Так что я сочувствую тому, к чему приводит этот ответ, но -1 даже за то, что я не признаю другую сторону этого компромисса.
Ведущий не командный игрок. Мы всегда оказываемся в ситуациях, когда у нас есть разногласия. Если вы не можете приспособиться к пожеланиям команды или руководства, вы всегда можете уйти.
Прежде всего, форматирование кода и подсветка синтаксиса — это разные вещи, и их следует рассматривать отдельно. В США подсветка синтаксиса может быть включена в условия ADA для нужд отображения с высокой контрастностью. Во-вторых, все современные IDE могут быть персонализированы для переформатирования и выделения на лету, а также могут переформатировать код в соответствии со стандартами компании при фиксации. Лучшим ответом должно было быть принятие стандарта компании И предоставление поддержки и разрешения программистам на персонализацию отображения кода для повышения удобочитаемости на их рабочих станциях. Иногда Боссу нужна задница, но не в этот раз.
Я проголосовал против, потому что аргументы в этом ответе касаются общей необходимости последовательного стиля кодирования , тогда как конфликт OP возник по поводу навязывания определенного инструмента . Я чувствую, что это не то же самое: стиль кодирования не обязательно требует обязательного инструмента.

Я бы попытался убедить его в положительных эффектах единообразного форматирования кода. Дифференциалы Git становятся намного проще для восприятия, когда коммиты n и коммиты n+1 имеют одинаковое форматирование. Сопровождение упрощается, если форматировщик применяет передовые методы. В конце концов, разработка корпоративного программного обеспечения — это командный вид спорта.

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

Самым большим преимуществом легко воспринимаемых различий является то, что теперь вы концентрируетесь только на фактических различиях кода, и вам не нужно тратить свое ограниченное когнитивное внимание на несущественные изменения форматирования. Или, учитывая, что вопрос касается Python, изменения форматирования могут быть или не иметь значения. Наша команда начала делать коммиты только для форматирования, за которыми следует коммит фактического изменения кода, чтобы избежать этой самой проблемы.
+1, я бы с тобой поработал. Этот ответ - единственный, который не пытается убедить сотрудника в том, что реализация - правильный путь, но что нужно помнить о цели . Предлагая свой вклад, он может внести свой вклад в наилучшее решение. Ответы вроде «Скажи ему смириться или уйти» — это мусор. Это не лидерство.
«Git diffs становится намного легче переваривать, когда коммит n и коммит n+1 имеют одинаковое форматирование». с другой стороны, их становится намного труднее переварить, когда вы вынуждены изменить отступ большого блока кода только для того, чтобы добавить или удалить условное выражение.
Я чувствую, что это более эмоционально интеллектуальный ответ. Мой технический руководитель спорил с нашим менеджером об определенных стандартах процесса, но обычно они соглашаются попробовать его на четверть и продолжить разговор. Подход «смирись и смирись с этим» — не моя чашка чая, даже если у сотрудника плохое отношение. Как менеджер вы должны подняться выше и не опускаться до этого уровня.
+1 за вопрос, есть ли у него идеи по улучшению. Всегда вполне возможно, что могут быть законные причины, по которым конкретный стандарт кода не идеально подходит, поэтому иногда стоит подумать об изменениях, но только если есть веская причина, что это улучшает читабельность и структуру, хотя, если он думает, что форматирование кода никакой пользы, я полагаю, у него вряд ли есть предложения.
Этот. Я бы также искал поддержку IDE (встроенную или подключаемую), которая будет переформатировать код в определенный стиль или, что еще лучше, в несколько стилей. Пусть разработчики работают как хотят. Последним шагом перед фиксацией является «форматирование кода по стандарту».
@PeterGreen, одна из прекрасных вещей, которые можно сделать с git, - это переписать историю, чтобы все было в очерненной форме с момента первоначальной фиксации . Сделайте это и добавьте постоянное исполнение, и у вас не будет изменений без семантического значения в истории... никогда.
@ivanivan Это будет второй последний шаг. Последний шаг, конечно, проверить его, чтобы убедиться, что он все еще работает.
@PeterGreen, вы бы не зафиксировали форматирование и свои изменения в одной и той же фиксации. Для этого и нужны коммиты форматирования.

Как бы вы поступили в такой ситуации?

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

Предыстория и вспомогательный опыт

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

Одна из проблем с автоматическим форматированием заключается не только в том, что оно «стандартизирует» плохое форматирование, но и в том, что оно «стандартизирует» хорошее форматирование.

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

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

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

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

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

Несмотря на то, что синтаксис Python уже предъявляет ряд требований к форматированию, он по-прежнему оставляет большую свободу для отдельного разработчика.

Суммируя. Прислушайтесь к возражениям ваших разработчиков, возможно, вы сможете улучшить кодовую базу для всех. Как говорится в PEP 8, в Руководстве по стилю кода Python.

Глупое постоянство — это хобгоблин маленьких умов

Он находится прямо в верхней части руководства по очень веской причине.

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

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

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

Кажется, это единственная часть PEP 8, которую люди игнорируют (ладно, хорошо, это, и многие люди поняли, что 80 символов — нелепый анахронизм). Выровненные по вертикали похожие части строк лучше. Сразись со мной.
Ограничения в 80 символов популярны не потому, что они были в терминалах 30-летней давности, а потому, что так гораздо удобнее сразу увидеть, что делает код, когда вы просто сканируете его глазами. Длинные строки убивают читабельность. Типографские руководства для текста обычно рекомендуют 45-70 символов в строке. Я часто форматирую свои блоки комментариев до ширины около 60 строк, потому что считаю, что это лучшая читабельность.
Этот ответ затрагивает некоторые важные проблемы с автоформатированием, которые редко решаются; Я бы посчитал осторожное использование нестандартных пробелов, которые не влияют на функциональность, «скрытой особенностью» программирования, и иногда это действительно может помочь. Единственные контраргументы, которые я когда-либо слышал против этого, более или менее «ну, тогда вы тратите больше времени на макетирование, чем на форматирование», но я никогда не считал такую ​​работу пустой тратой времени и не считаю часами занимаюсь этим...
... и я думаю, чтобы привести конкретный пример: 1) Кто-нибудь может заявить, что маркированные списки с отступом в Stack Exchange бесполезны? 2) Все бы предпочли, чтобы они удалили это ради «стандартизации»? 3) Вот пример того, как это будет выглядеть. Думаю, я бы предпочел, чтобы программистам были предоставлены все те же ресурсы, что и писателю (когда это практично, я знаю, что размеры шрифта и полужирный / курсив были бы проблематичными); удалите пробелы в конце строки и задайте отступ табуляции вместо пробела, конечно, но я не сторонник убирать инструменты для хорошего представления идей.
Хотя вы делаете несколько хороших замечаний, я не видел в вопросе упоминания об автоматическом форматировании. Я категорически за стандарты кодирования, но презираю автоматическое форматирование, так как результат обычно оставляет желать лучшего. Как и где соответствовать стандартам (например, как лучше всего разбить линию) — это задача, которую лучше оставить людям. mguijarr может применять стандарты кодирования без использования автоматического форматирования.
-1 Workplace.SE — это работа с людьми, а не технические решения. Ответ Васмачиена, по крайней мере, описывает, как использовать технологию, чтобы убедить человека.
Я не понимаю, как ваш комментарий помогает мне улучшить мой ответ @Chris, мои основные моменты ориентированы на людей, мои технические моменты здесь только для того, чтобы усилить потребность в общении.
@MarkBooth: вы пишете о пробелах, слиянии и руководствах по стилю Python. Если там и есть советы, ориентированные на людей, то они тонут в технических деталях.
Конкретный ответ находится прямо вверху @Chris, его трудно не заметить. Остальное подтверждается доказательствами из личного опыта пребывания в ситуации, аналогичной ситуации, когда разработчик находится под «управлением».
@MarkBooth На самом деле это трудно пропустить. Ваш совет - два маленьких предложения в очень длинном ответе. Но другие, кажется, считают, что это подходящий ответ, поэтому я оставлю это.
«Если вы собираетесь внедрить автоматическое форматирование, вам нужно, чтобы в этом участвовала вся команда». - этот! Выгода от этого приходит, когда все делают это. Вы можете захотеть, чтобы цепочка инструментов сборки проверяла исходные коды во время компиляции (и терпела неудачу, если они неправильно отформатированы), или чтобы ваш инструмент контроля версий проверял во время отправки.

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

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

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

Это не означает, что нет веских причин для установления стандарта.

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

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

Мне нравится аналогия. Считайте, что это украдено для будущего использования!
Аналогия немного сбивает меня с толку, потому что неформатированный код функционирует так же, как и форматированный, чего нельзя сказать о хлебе. Маленькая буханка не справится с работой большой буханки. Очень трудно сравнить эту концепцию с осязаемым, физическим благом.
@Geobits Круглая буханка работает так же, как прямоугольная, но для них определенно требуются разные сумки.
Я думаю, что это хороший ответ, поскольку он показывает, что то, что, вероятно, отсутствует в вопросе, является причиной стандарта форматирования кода. Или, по крайней мере, нет единого мнения о важности стандарта.
@ user1234567890abcdef Да, но это все еще разные хлебцы, тогда как с кодом конечный продукт не отличается. Форматирование кода больше похоже на то, чтобы заставить всех ваших пекарей организовать свои рабочие места одинаково, чтобы они были взаимозаменяемыми, и все знали, где что находится, если им приходится работать в другом месте. Тоже не идеальная аналогия, но мне ближе.
@Geobits - несколько лет назад в некотором программном обеспечении Apple была серьезная ошибка SSL, которая вызвала сбой в форматировании кода (т.е. запись двух строк кода в операторе if). Пример может быть не совсем точным, я забыл точную деталь, но это была довольно глупая ошибка кодирования. Дело в том, что стандарты кода служат определенной цели.
Эта аналогия разваливается, поскольку ожидается, что результаты программистов будут иметь высокую степень оригинальности, тогда как хлеб должен быть однородным. Можно спорить о том, всегда ли программа форматирования кода должна преобладать над суждениями программиста-человека (при условии, что созданный человеком код разумно соответствует руководству по стилю и что отклонения имеют свои обоснования).
Я очень не люблю аналогии в программировании. Они могут показаться полезными, но обычно проще говорить о программировании, когда ваша целевая аудитория состоит из программистов.
@Ramhound Верно, но это было бы обнаружено, только если бы неправильное форматирование привело к ошибке. OP использует инструмент, который автоматически форматирует неправильно отформатированный код.
@Marc.2377 Marc.2377 Это круто; Я очень люблю аналогии в программировании, где это имеет смысл. Мне кажется, что этот вопрос касается не столько программирования, сколько стандартов в действии.
@PeteCon Рад быть полезным!
@Geobits Я думаю, что функцию хлеба немного сложно определить, но, возможно, она работает так же, хотя вы правы, аналогия на самом деле не очень длинная. Я думаю, что это означает суть этого вопроса, хотя
@200_success Я категорически не согласен с этим; код, который пишут люди, вообще не требует оригинальности; к конечному продукту может предъявляться требование быть оригинальным. Клиентам все равно, оригинальный у вас исходный код или нет.
@Geobits Плохо отформатированный код может работать, но с ним будет сложнее работать в будущем. То же самое верно и для разных размеров хлеба. Талантливый человек может работать с меньшим размером хлеба, но если размеры хлеба остаются одинаковыми во всем, над ним может работать более широкий круг сотрудников по сравнению с несколькими высококвалифицированными людьми. То же самое относится и к плохо отформатированному коду, так как талантливый человек может работать с ним, но для большой аудитории это может быть не так просто, если бы у всех был стандарт.
Выпечка стандартных порций хлеба – это сдельная работа. Программирование — это не штучная работа, если только вы не очень в этом разбираетесь.
@ Брайан Боюсь, я не согласен с тем, что выпечка хлеба — это «сдельная работа». Я также не уверен, что вижу, как разница в типе работы влияет на применимость стандартов качества.
@Donald Похоже на nudesecurity.sophos.com/2014/02/24/… На самом деле переформатирование помогло бы поймать ошибку, поскольку она переместила бы второй переход влево под if.
Я знаю, что переформатирование поймало бы это.

"форматирование кода - полная ерунда"

Даже если это имело смысл (а это не так), подобные черно-белые утверждения часто намекают на очень незрелое понимание :

  • как обращаться с инструментами разработчика и обсуждать их плюсы и минусы в сбалансированной и контекстно-богатой манере (то есть профессионально)
  • как работать в команде

Нам нужны профессиональные и конструктивные мнения, а не фанатичные аксиомы.

«это как цвета, кому-то нравится красный, кому-то синий, вот и все» / «это ограничивает мою свободу»

Нет, это не похоже на цвета. Речь идет о читабельности и общих стандартах .

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

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

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

Представьте, если:

  • у разработчика А есть свой стандарт
  • разработчик B использует другие стандарты форматирования
  • новый разработчик "C" должен был бы читать код в двух разных стилях
  • Д через три... и так далее.

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

А что, если они редактируют один и тот же файл/класс? Придет ли это к разным стилям кодирования?

«это делает код более сложным для чтения без добавления ценности»

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

Изменить: пожалуйста, посмотрите также на ответ @nitarshs , он дает еще один интересный угол с точки зрения групповой психологии, который мне показался интересным.

@NathanHughes нет, может быть, плохая формулировка, я не являюсь носителем английского языка. Я хотел сказать «люди, которые с такой легкостью разбивают инструменты».

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

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

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

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

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

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

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

Дело вовсе не в форматировании кода. Это худшая из возможных форм микроменеджмента. Всякий раз, когда совершается коммит, глупый бездумный микроменеджер изменяет код глупым микроуправлением. И этот разработчик в бешенстве. (Кажется, некоторые этого не поняли — когда я говорю «микроменеджер», я имею в виду инструмент форматирования кода).

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

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

Согласованное форматирование кода значительно упрощает работу с кодом других людей и облегчает сравнение. На мой взгляд, речь идет о профессионализме и командной работе, а не о микроменеджменте. Нигде не сказано, что менеджер вносит изменения в код, это разработчик должен вносить изменения в код перед фиксацией.
Я думаю, вы делаете несколько необоснованных предположений: что выгода равна нулю, и что человек, о котором идет речь, был достойным разработчиком, потеря которого связана с необходимостью работать более эффективно с остальной частью команды. Я тоже не думаю, что это правильно: в большинстве проектов выигрывает эффективность (например, код-ревью требует меньше расшифровки чьего-то «творческого» стиля), и, судя по всему, у этого человека уже есть проблемы с работой в команде, и это проявление это, а не причина.
Смысл инструмента форматирования кода состоит в том, чтобы исключить все придирки, которые происходят в обзорах кода. Здесь нет участия микроменеджера; средство форматирования кода делает свою работу, вот и все.
@DanielRoseman Если у вас есть рецензенты кода, придирающиеся к форматированию кода, то у вас настоящая проблема. И я не знаю, достаточно ли ясно выразился - инструмент форматирования кода - это микроменеджер.
@ gnasher729 нет, это костыль для тех коллег, которые не удосуживаются предоставить чисто отформатированный код. Если бы он сделал это «правильно» сам, инструмент не внес бы никаких изменений. Очевидно, что нет. Таким образом, это способ предотвратить любое обсуждение, когда кто-то другой увидит, что изменения отменяют все красивое форматирование и загрязняют проверку кода.
При этом может случиться так, что этот инструмент или форматирование, которое он делает, плохо выполняет свою работу. Но это уже другой момент от наличия такого инструмента вообще.
Я никак не мог подсчитать общее время, потерянное из-за нашей неудачной попытки внедрить автоформатирование в нашу унаследованную кодовую базу несколько лет назад. Даже сейчас нам приходится тратить время на исправление случайного конфликта слияния из-за внесенных за это время изменений.
Приравнивание стандартов форматирования к микроменеджменту неверно на многих уровнях.
Вам действительно нравится форматировать код вручную? Я стал полностью зависим от автоматического форматирования, которое мы используем на работе. Это черная задача, которую я очень рад оставить автоматизированному инструменту. Я слишком стар, чтобы заботиться о том, чтобы всегда правильно форматировать каждую исходную строку.

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

Я думаю, что проблема лучше всего проиллюстрирована удалением деталей из вашего вопроса:

Я руководитель небольшой команды разработчиков

-- Я принял решение о том, как мы будем работать --

С тех пор коллега всегда жалуется и выражает несогласие с этим решением

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

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

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

Более того, причиной, вероятно, является и проблема людей. Пока этот коллега протестует против результата изменения, он может на самом деле возражать против способа, которым было сделано изменение, или какого-либо другого аспекта изменения. В этом случае форматирование — это просто отвлекающий маневр, реальная проблема заключается в чем-то другом, и решение состоит в том, чтобы обсудить с ним ситуацию, выяснить, в чем заключается настоящая проблема, и решить ее.
Если вы хороший и эффективный менеджер , никогда не должно быть необходимости в принудительном выполнении принятого вами решения .
Авторитарное управление может быть эффективным в некоторых средах, но для работников умственного труда это бывает редко. Если вы гордитесь своей работой, то микроуправление, отмена ваших решений или игнорирование вашего мнения могут стать серьезным препятствием для продуктивности и творчества. Когда дерьмо попадает в вентилятор, ваш менеджер должен держать зонтик, пока вы его ремонтируете.
@MarkBooth полностью согласен с этим. Я предполагаю, что это решение было принято с учетом мнения большинства членов команды — очевидно, если против него выступает не только этот человек, или если после того, как он попробовал это на практике, его возражения имеют смысл, и он изменит ваше / мнения других членов команды, то, конечно, вам следует пересмотреть решение.
Я не совсем уверен. Учитывая «по предложению другого коллеги» и «я нахожу ценность» в другом месте, я предположил, что «мы представили» использовали Royal we . Это обычная черта авторитарного управления, когда диктат отдельного менеджера прикрывается ложным или газлитовым консенсусом. «Помните, мы все договорились об этом на прошлой встрече?», «Нет, вы предложили, я объяснил, почему это не сработает, и вы сказали, что мы обсудим это позже». Может быть, я просто становлюсь циничным в старости. *8')

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

С тех пор коллега всегда жалуется и выражает несогласие с этим решением

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

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

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

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

Я согласен. Правильный код должен выглядеть правильно, а неправильный код должен выглядеть неправильно. Сила этого заключается в том, что человеческий мозг, будучи машиной, ищущей закономерности и создающей значения, будет снова и снова анализировать закономерности кода, которые он видит, а затем вырабатывать «чувство», когда что-то выглядит не так, с все это происходит без сознательного усилия. В конце концов, ошибки обнаруживаются или даже не пишутся, потому что «неправильный код выглядит неправильно». Когда команда непоследовательна, каждый отдельный член будет получать ложные «предупреждения» о неправильном коде только для того, чтобы обнаружить, что это просто разница в форматировании. Плохо.
@CodeSeeker: хорошо сказано.

Далеко не полный ответ, но здесь есть один момент, который мне бросается в глаза. Форматирование кода в ваших коммитах никоим образом не должно совпадать с форматированием кода, используемым в IDE разработчика, пока они работают с локальной копией репозитория. Я не знаю, чтобы я когда-либо работал над совместным проектом, где код каждого разработчика не был бы отформатирован именно так, как они хотели. Применение форматирования при фиксации достаточно легко настроить с помощью git hooks .

Полностью согласен с этим ответом. хуки перед фиксацией - это ответ. Другие инструменты VC имеют аналогичные элементы управления. Самое простое применение для этого — обеспечить согласованные окончания строк в смешанных средах разработки. Разработчик волен делать все, что ему нравится, но хук фиксации обеспечивает «чистую» фиксацию.
Это именно то, о чем я думал, то, как я форматирую код, сильно отличается от того, как другие разработчики в моей группе форматируют свой код. Когда они открывают мой код в своей IDE (обычно мы используем VS Code для веб-материалов и VS Studio для настольных компьютеров), он отображается в их формате. По общему признанию, мы не пишем Python, который требует строгой обработки отступов, но нет никаких причин, по которым то, как данный разработчик отформатировал свой код, должно влиять на то, как другие форматируют свой код.
@delliottg: Да, и использование такого автоформатера может решить проблему Python, когда код, написанный кем-то, кто использует буквальные табуляции для отступов, разваливается в редакторе с другим интервалом табуляции.
И у нас именно так, один из наших старших разработчиков любит использовать пробелы для отступов, я предпочитаю вкладки, но я не переформатирую его код, чтобы удалить пробелы, и он не меняет мои вкладки на пробелы. (Помните, что мы не используем Python или другие языки с отступами). Время от времени мы спорим об этом, но ни для кого из нас не так уж важно, что мы хотим навязать это с помощью линтера или какого-либо другого инструмента.
Я не уверен, что люди, которые предлагают это, на самом деле являются разработчиками, работающими с кодом. Автоматическое переформатирование превращает слияния, нумерацию строк и различия в кошмар.

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

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

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

Эти случаи не отличимы от вашего поста. В зависимости от того, что происходит, вы можете или не можете поговорить с другими разработчиками и выяснить, что это такое. Однако остерегайтесь позиции «Я считаю, что так лучше, потому что так считает босс»; это не будет говориться с вами, но я видел, как это падало раньше.

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

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

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

У вас откровенный разговор о том, что означает слово "профессионализм".

Ваш «ведущий разработчик» ведет себя как надутый ребенок. Он/она может обладать техническими навыками лидера, но ему явно не хватает профессиональных навыков лидера. Речь идет не только о написании кода: технические навыки являются необходимым , но недостаточным условием для этой должности. Быть ведущим означает, по крайней мере для меня, понимать, что дело не в тебе . Это не означает, что вы не ведете переговоры и не защищаете себя, это означает , что вы не устраиваете истерику по поводу того, что является передовой отраслевой практикой, даже если в частном порядке вы считаете это чушью (смотрите на вас, JIRA ).

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

РЕДАКТИРОВАТЬ на основе разговора в комментариях

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

Я знал нескольких программистов, которые не могли понять необходимость единых стандартов кодирования. Если они этого не понимают, я гарантирую, что в программировании будут другие важные вещи, которых они не смогут понять. От этого нет лекарства.
@ Эд Планкетт: Но есть разница между постоянным и хорошим. Я знал людей, которые применяли идеально согласованное форматирование кода, что делало их код почти нечитаемым — во всяком случае, для меня. Может быть, у них по-другому работает мозг?
@jamesqf «Последовательно» в том смысле, что вся команда делает это одинаково, предпочтительно способом (PEP3 в случае OP), который распространен в отрасли и легко понятен новым членам команды. В C# в моей команде мы используем значения по умолчанию VS. Не мой личный фаворит, но очень чистый и очень близкий к универсальному — что намного лучше, чем просто соответствие моим личным эстетическим стандартам.
@jamesqf Парни с «мозгом работают по-другому» — это те, у кого неизлечимые проблемы с пониманием, о которых я упоминал. Им нравится быть трудными. В индустрии, полной тактично «ненейротипичных» людей, вы получаете некоторых из них.
PEP 3 - это руководство по обработке отчетов об ошибках @EdPlunkett, я думаю, вы имели в виду PEP 8 , а черный цвет выходит далеко за рамки PEP 8.
@МаркБут. Правильно, это была опечатка. Спасибо. Я хотел сказать, что OP не применяет какой-то странный произвольный набор соглашений о форматировании.
Взглянув на черный цвет , форматирование, которое он применяет, довольно странное @EdPlunkett. Я, конечно, никогда не видел, чтобы кто-то писал вручную код, похожий на формат, который он генерирует, и я поддерживаю продукт, который содержит встроенный интерпретатор python, поэтому я вижу всевозможные странные и замечательные пользовательские python. На самом деле я одобряю изменения, которые он вносит, теоретически, но вы не можете ожидать, что всем он понравится с места в карьер, не имея возможности привыкнуть к преимуществам, которые он потенциально предоставляет.
@MarkBooth, аргумент не касается достоинств этого конкретного формата (или его отсутствия), коллега OP против стандартного форматирования, и точка. Я не большой поклонник PEP 8 в нескольких отношениях, но это не обо мне. Споры о том, какой стиль форматирования лучше, предназначены для бара (мне они нравятся не меньше, чем для очередного самоуверенного дерьма), а не для зала заседаний.
Это, вероятно, следует переместить в чат на рабочем месте @JaredSmith, но моя точка зрения заключалась в том, что использование черного цвета не является бесспорным решением, я вижу, что это очень сильно раздражает некоторых людей. Этого определенно не стоило делать без участия ведущего разработчика проекта. ОП вообще никогда не должны были оказаться в таком положении.
@MarkBooth согласен с вами насчет чата. Я не уверен (после прочтения вашего ответа), что не согласен с вами, у нас недостаточно информации, чтобы судить. Но я определенно работал с разработчиками, которые настаивали, несмотря на то, что в конечном итоге им угрожали расторжением контракта из-за их собственного странного нечитаемого форматирования, потому что, цитирую, «это то, к чему я привык и не хочу менять». Если у разработчика есть законные возражения, то есть способ их высказать. Но, судя по моему прочтению тона вопроса, он больше похож на случай с шипением, чем на тщательно продуманный случай.
Я подозреваю, что «шипение» произошло только после того, как авторитет ведущего разработчика уже был необоснованно подорван. Помните, что мы слышим это только с точки зрения ОП, поэтому лучшее, что мы можем сделать, это читать между строк. Теперь речь идет о возмещении ущерба, а это означает, что нужно слушать, а не диктовать им, что такое «профессионализм», или говорить о дисциплинарных взысканиях, как это делает этот ответ. Говоря об этом, вы можете определить, что вы подразумеваете под «перейти к PIP». Я предполагаю, что вы имеете в виду "План повышения квалификации", но я не уверен.
@MarkBooth да, план повышения производительности. И нет, я понимаю теперь, что я с вами не согласен: даже если авторитет был необоснованно подорван (а вы правы, может быть, и так), вы прямо заявляете об этом , причем наедине . Вы не сделаете этого, ворча об этом инструменте на публике. Я называю махинациями.
@EdPlunkett Включая раздел PEP 8 (я полагаю, вы имели в виду 8), в котором говорится: «Глупая последовательность - это Хобгоблин маленьких умов»?
@immibis Спасибо. Этот комментарий так прекрасно отражает целое мировоззрение.

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

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

Пара хороших статей, которые я только что нашел с помощью быстрого поиска:

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

Это не комментарии компетентного ведущего разработчика. Я говорю это как опытный программист и менеджер инженеров-программистов.

Обратная связь неконструктивна и крайне неверна. Ведущий разработчик, который не понимает ценности стандартов форматирования, — это ведущий разработчик, который не понимает динамики совместной разработки.

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

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

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

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

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

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

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

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

-1 Это не ответ на вопрос. Да, форматирование кода — это хорошо, но ОП уже это знает.

Многие другие ответы обсуждают, стоит ли форматирование кода того или нет. Это совершенно не имеет отношения к этому вопросу.

Речь идет об общении, а не о том, чтобы убедить его в том, что стандартизированное форматирование кода — это здорово. Сделать шаг назад. Что вам нужно для общения:

  • Чего вы пытаетесь достичь.*
  • Как вы планируете измерять успех.

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

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

  • Слушай их. Они оплачиваемые профессионалы, и их опасения могут быть более обоснованными, чем вы думаете.
  • Заткни их. «Это решение. Я знаю, что оно вам не нравится, и я слышала ваши опасения, но теперь мне нужно, чтобы вы приняли его и работали с командой».

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

форматирование кода полная ерунда

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

это как цвета, кому-то нравится красный, кому-то синий, вот и все

Ага. Это относится практически к любому спору о программировании. Табуляции и пробелы, скобки в стиле C или египетские скобки... Но ответ всегда один и тот же: кому-то нравится левостороннее движение, кому-то правостороннее. Любое из них прекрасно, но одновременное допущение того и другого ведет к безумию.

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

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

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

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

это уменьшает мою свободу

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

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

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

это делает код более сложным для чтения без добавления ценности

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

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

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

Когда вы говорите «нельзя», вы имеете в виду, что это не разрешено или что это невозможно (например, рецензент всегда отклонит запрос)?

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

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

Так что вы слепо верите тому, что вам сказал ОП. Он явно терпит неудачу как менеджер и хочет поддержки здесь, поэтому я не верю, что какие-либо его цитаты точны.
@gnasher729: Это не вопрос веры. SE не имеет формата, который позволяет контрагенту сообщить свою сторону, а затем позволяет нам проводить арбитраж между двумя противоборствующими сторонами. Формат вопросов и ответов по своей сути привязывает нас к содержанию заданного вопроса. Я могу ответить на вопрос только в том виде, в каком он задан, его применимость в реальной жизни полностью зависит от того, насколько сам вопрос основан на реальной жизни. Хотя обычно это и ожидается, настоящей защиты от вымышленных или искаженных ситуаций не существует.
@gnasher729: Во-вторых, по какому критерию вы оцениваете ОП как «неудачного менеджера»? Они не знают, как подойти к сотруднику, который, по опыту OP, сопротивляется командному соглашению без какой-либо реальной причины, кроме нежелания адаптироваться. Как попытка решить проблему и получить дополнительную информацию приравнивается к неудаче в качестве менеджера? Вы обращаетесь ко всем опубликованным вопросам на SO / SE и указываете на некомпетентность каждого ОП, потому что они не знают ответа на свой вопрос?

Вы менеджер, поэтому давайте попробуем управлять им (и этим), а не просто отчитывать его или рассматривать его как проблему:

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

«Когда большинство разработчиков просматривают код, будет быстрее, если они смогут принять некоторые вещи как должное, например способ выполнения кода и способ стандартизации некоторых вещей . аудит кода? Ответственность? Должная осмотрительность?] , лучше, если он будет стандартизирован. Вы правы, что некоторым нравится синий, а некоторым красный, и вне работы мы с вами оба можем кодировать так, как нам нравится. Но пока мы при написании кода, который команда должна поддерживать, а будущие инженеры должны быстро и точно понимать, я верю, что стандартизация поможет, и я возглавляю команду — не вы, не Боб, не Алиса, поэтому я должен сделать такого рода звонки, если я чувствую необходимость — и я это делаю».

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

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

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

Пробелы на самом деле являются частью pythonсинтаксиса. Удобочитаемость уже разработана в языке. На самом деле у python есть свои рекомендации по форматированию кода. Лучшие практики, соглашения об именах и т. Д. Это называется PEP (точнее, PEP8). Начните там! Знание PEP — это то, что они могут добавить в свое резюме!

Как бы вы поступили в такой ситуации?

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

Я думаю, что хорошим следующим шагом будет решить, продолжать ли использовать этот инструмент. Если вы считаете это полезным, объясните, почему . Например, если Конечный пользователь/Клиент дает вам лучшие обзоры или будущие проекты, потому что код красивый — скажите об этом своим сотрудникам! Это означает, что у них в кармане больше денег!

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

Только один разработчик в команде возражает против последовательного форматирования, а не четыре. Упомянутый инструмент OP, черный, обеспечивает PEP8 . Неправильно утверждать, что единообразное форматирование кода снижает чью-либо производительность. Как раз наоборот: ценность последовательных привычек кодирования ( включая форматирование) заключается в простоте обслуживания. Производительность труда программиста не зависит от того, сколько операторов if он может ввести за данный час.
@EdPlunkett Забавно, что вы говорите «применяет PEP8», потому что в одном разделе PEP8 говорится, что его не следует применять. Следовательно, применение PEP8 на самом деле не соответствует PEP8.
@immibis Ты подарок, мой друг. Абсолютный подарок. Я никогда не знал, что суверенное гражданство было перенесено на Python.
@EdPlunkett Я номинирую это на самый бессмысленный комментарий месяца.
В самом верху PEP8: A Foolish Consistency находится Hobgoblin Little Minds !

Два дополнительных момента, возможно, заслуживают внимания.

  1. Вы просите черно-белый ответ для проблемы с оттенками серого. Ваши правила форматирования кода могут быть разумными, могут быть смягчены, могут быть придирками. Я видел все виды правил. Итак, прежде всего, проверьте, действительно ли правила формата кода, которые вы требуете, разумны или нет.
  2. Было ли форматирование кода и все стандартные правила кода просто навязаны сверху или согласованы разработчиками в команде — теми, кто собственно пишет код и кто читает/использует код от других? Может быть хорошей практикой принять решение о наборе стандартных правил кодирования комитетом - только один раз, а затем эти правила применяются. Если большинство разработчиков с ними согласны, то у вас есть высокая вероятность того, что эти правила разумны, а если кто-то жалуется, скорее всего, проблема в нем. Если бы правила были просто навязаны указом одного человека... тогда у вас могут быть проблемы.
  3. Альтернативой является поиск инструмента проверки/форматирования кода, который является более или менее отраслевым стандартом для используемого вами языка. Например, для C# я использую Resharper. Тогда решение будет непредвзятым, а форматирование можно будет сделать более-менее автоматически в редакторе по мере написания кода. Если Resharper счастлив, я счастлив. Найдите что-нибудь подобное для Python.

Мое личное эмпирическое правило, когда я возглавляю команду, состоит в том, чтобы настаивать на строгих правилах только тогда, когда чей-то код выглядит действительно уродливым... и если это произошло, мы могли бы рассмотреть более глубокую проблему, чем просто форматирование кода. Проблема, которая начинается с HR и найма не того человека. В противном случае, если код выглядит более-менее понятным и организованным, а его архитектура/дизайн хороши, придирки к форматированию часто вызывают больше проблем, чем пользы.

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

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

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

В дополнение к другим ответам, которые уже довольно хорошо освещали The Talk , — методология внедрения форматирования в ваш процесс, нравится это Бобу или нет:

Делайте обзоры кода, используя принцип четырех глаз для каждого мерж-реквеста. Вы masterдолжны быть изменены только с принятым запросом на слияние, никак иначе. Все запросы на слияние должны проходить проверку качества, т. е . другой член команды должен просматривать код. Включите форматирование и позвольте MR Боба быть отклоненным из-за неправильного форматирования кода.

Если Боб откажется подчиниться, то его мерж-реквесты застрянут в подвешенном состоянии. На вопрос «Почему функция XY не реализована, несмотря на то, что крайний срок уже давно прошел?», Боб может ответить: «Это было сделано некоторое время назад, но коллега Y отклонил ее». Можно возразить, что это потом не делается. Для этого и существует контроль качества. Коллеги должны отклонить такие запросы и переназначить Боба, тогда работа Боба должна справиться с этим.

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

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

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

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

Большое нет. Он склонен к несоответствиям, и вся команда не должна приспосабливаться к беспочвенному нытью одного.
Мне нравится ваша идея, но есть слишком много вещей, которые инструментарий не может исправить (например, что-то в комментариях, например, пример кода в аннотациях autodoc, любой новый синтаксис, для которого он не был исправлен, и т. д.). Не стоит постоянно перепроверять код нарушителей и проходить множественные проверки кода при каждом запросе на включение.
Я не знаю, насколько это актуально для python, но раньше у нас был инструмент (более ограниченный сравнением/слиянием), который знал о синтаксисе языка и делал синтаксически осведомленные различия.
Это звучит смехотворно подвержено ошибкам, и тип коллеги кажется мне человеком, который выступает против любого стиля кода или автоисправления (т.е. он не последователен в своем собственном стиле). Это неосуществимо.

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

Разговор, который у меня был бы, больше похож на: вы только что назвали мои инструкции и решение команды "чушью"? Вы действительно жаловались, что оплата за работу «ограничивает вашу свободу»? Я настоятельно рекомендую вам прямо сейчас проверить правильно отформатированный код, и я организую встречу с HR, чтобы обсудить уважение к вашему работодателю, менеджеру и команде.

То есть вы говорите, что решение правильное, потому что оно исходит сверху и к нему должно быть уважение? Я бы сказал нет, это точно не то, как должны работать технологические компании, кодеров нужно убеждать в том, что они делают и как, а не заставлять. Это было бы очень непродуктивно и даже опасно.
@Mayou36 Mayyou36 Нет, я имею в виду: называть командные инструменты «черт возьми» выходит за рамки профессионального общения, особенно если у вас нет веских аргументов. И заявление о том, что руководящие принципы на работе «ограничивают вашу свободу», — это своего рода странное понимание рабочего контракта. Особенно для чего-то, что на самом деле является командной темой.
@Mayou36, может быть, вы публикуете комментарий к неправильному ответу. Этот ответ касается политической/межличностной стороны вопроса и не дает никакого суждения о технической проблеме: он считается «здравым», поскольку согласован руководством и командой, кроме одного.
Нет, Майоу права. Когда вы нанимаете программиста (или кого-то еще), вы получаете бесплатно мозг с каждым сотрудником. Если вы запугиваете их — а этот ответ будет запугивающим, даже если некоторые могут считать его действительным / законным — вы подрываете моральный дух и производительность. Другие узнают, что вы так реагируете, и между вами и командой возникнет пропасть, и то, что вам нужно услышать, не будет сказано вам в ущерб вам и команде. Плохие менеджеры рано принуждают. Хорошие менеджеры пробуют совместные подходы и откладывают жесткие линии до тех пор, пока они действительно не понадобятся из-за срочности или по другим причинам...
... подходы не увенчались успехом. Но, несмотря на разговоры в ОП, я не вижу в вопросе ничего, что указывало бы на то, что точка была достигнута, потому что не описано описание какой-либо попытки фактически и надлежащим образом справиться с ситуацией. ОП спрашивает, как с этим справиться прямо сейчас. Таким образом, запугивание — это слишком много, и я бы поговорил с любым менеджером, который, как я видел, наносил ущерб его команде, если бы видел это без действительно веской причины — которой пока не существует: и используя эту ситуацию как способ улучшить свои навыки управления персоналом - и проверить, не скрывается ли у нас проблема с культурой.
@Stilez: Информирование сотрудника о том, что в какой-то момент неподчинение и отказ от командной работы могут иметь профессиональные последствия, не является травлей. Вызов "б*****т" тому, что говорят ваши коллеги.
"В какой-то момент"... И таким образом. Это больше манера, чем информация, которая заставляет меня рассматривать это как запугивающий ответ. Одна и та же информация может быть предоставлена ​​разными способами, и проблема может быть решена разными способами. Эскалация до подразумеваемой угрозы просто не нужна или не полезна для OP, как описано, и ответ не кажется подходящим суждением о том, где находится эта точка, и не показывает понимания управления - межличностных навыков и построения команды. Вы можете выиграть спор силой, но все же потерять свою команду, добрую волю, сотрудничество и (в долгосрочной перспективе) войну. Этот ответ ведет в этом направлении.
Что касается «команда приняла правильное решение о том, как действовать», у меня сложилось впечатление, что это решение приняла не команда в целом, а скорее менеджер, который принял решение и хочет получить наш совет о том, как он / она может навязать это своей команде. Отсюда и проблема.
@ Паоло, это моя точка зрения, если бы команда и руководство согласились с этим, я бы настоятельно не рекомендовал использовать «Я твой начальник» в качестве аргумента, чтобы заставить его следовать. Это похоже на «ультимативное соотношение» и должно использоваться для предотвращения ущерба, а не как бизнес-концепция, и, прежде всего, не для разработчиков. Привлеките его на свою сторону, не приказывайте ему что-то делать.
@Stilez: нет, запугивание было бы следующим: перед командой сказать: «Иди, собирай вещи и уходи в отставку.
Нет, вы можете подумать, что это не так. Делайте такие вещи регулярно, и ваши сотрудники расскажут другую историю, когда вернутся домой с работы. И это история, которая имеет значение, вы не можете переопределять GWB, что на самом деле пытка водой не является пыткой, или делать подобные угрозы (а они есть), поскольку ваш основной ответ на самом деле не издевательство. Они это увидят, и ваша команда проиграет. Не проявляйте агрессивного поведения, даже если вы не считаете, что это правильное слово.
Вопрос в том, кто хулиган в этой ситуации? Ведущий разработчик, чей авторитет в проекте только что был подорван и (в некоторой степени) по понятным причинам негативно отреагировавший на новость, или менеджер, который сейчас ищет способы заставить своего разработчика согласиться с его заявлениями? Наличие доступа только к одной стороне истории делает это трудным для определения. Насколько нам известно, комментарии, цитируемые ОП, могли быть сделаны ведущим разработчиком неофициально, в частном порядке, в баре после работы. Контекст — это все, и мы просто не знаем.
Марк: Или вообще нет. Потому что большинство цитат выглядят легкими изменениями вполне разумных утверждений.
Член команды категорически против форматирования кода
СпросиСетьПолитика конфиденциальности1y, 1v