Есть ли способ поддержать разные стили кодирования в команде разработчиков

Проблема: два разработчика => три мнения об отступе, скобки на новой строке или нет и т. Д.

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

Таким образом, вопрос заключается в следующем: есть ли способ позволить каждому программисту жить по-своему, но иметь общую базу кода внутри репозитория? Я думаю о каком-то плагине git / svn / what, который меняет личный и общий стиль при извлечении и фиксации. Мне кажется, что сложность этого подхода заключается в поддержке правильных различий между версиями файла.

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

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

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

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

ДА, это может работать до тех пор, пока все стили разумны, и люди не собираются менять код других людей в соответствии со своими предпочтениями и / или смешивать стили в одном файле кода.
Это не идеал, но он ничем не отличается от наследования старого кода, созданного в другом «стандарте», от вашего собственного, и необходимости его интеграции с вашей базой кода.
Так что, если вам нужно сделать это, некоторые рекомендации:

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

Краткий ответ: нет.

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

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

1. Элементы макета, такие как табуляция, отступы, использование {, (,,
2. Переменная, имя объекта и функции, т. Е. CamelCase, венгерская нотация
3. Обработка исключений, как / когда / где это должно быть выполнено
4. Кодовые комментарии. Вы всегда ссылаетесь на дизайн документа, номер ошибки и т. Д.

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

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

Обычно при создании документа Coding Standards я проверяю отраслевые стандарты для языка, который я использую (C, C #, SQL), использую наиболее подходящие стандарты, рассылаю комментарии наиболее старшим / влиятельным разработчикам, включаю комментарии, где это необходимо, а затем выпустить документ.

Теоретически возможно автоматическое переформатирование кода перед его передачей в вашу систему контроля версий.

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

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

Вот аналогичное обсуждение переполнения стека .

Одностороннее автоматическое переформатирование кода может быть эффективным решением, если вы:

1. Найдите автоформатор, который действительно работает для соглашения, которое вы хотите реализовать, и вашего языка программирования.
2. Можно выполнить предварительную фиксацию, чтобы переформатирование не отображалось в журналах изменений, смешанных и неотличимых от реальных функциональных изменений.
3. Добейтесь, чтобы ваша команда договорилась о том, какое соглашение следует применять (потому что, вообще говоря, нет никакого «обратного пути» при проверке личных предпочтений разработчика, по крайней мере, не так, как я знаю).

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

абсолютно вы можете. Все дело в том, чтобы не потеть мелочи.

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

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

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