Является ли навязывание одинакового формата кода всем разработчикам хорошей идеей?

Мы рассматриваем возможность введения в нашем проекте единого стандартного формата кода (автоформат с сохранением действий в Eclipse). Причина в том, что в настоящее время существует большая разница в форматах кода, используемых несколькими (> 10) разработчиками, что затрудняет работу одного разработчика над кодом другого разработчика. Один и тот же файл Java иногда использует 3 разных формата.

Поэтому я считаю, что преимущество очевидно (удобочитаемость => производительность), но было бы неплохо навязать это? А если нет, то почему?

ОБНОВЛЕНИЕ
Мы все используем Eclipse, и все знают о плане. Уже существует формат кода, используемый большинством, но он не применяется, поскольку некоторые предпочитают придерживаться своего собственного формата кода. Из-за вышеупомянутых причин некоторые предпочли бы обеспечить его соблюдение.

В настоящее время я работаю в месте, где применяется стандартный формат кода, и код автоматически форматируется при сохранении файла, как вы собираетесь это сделать. Как новый член компании, я обнаружил, что общие правила форматирования дали мне теплое и смутное ощущение, что «эти ребята знают, что они делают», поэтому я не мог быть счастливее. ;) В качестве примечания, касающегося общих правил форматирования, мы также применяем определенные, довольно строгие настройки предупреждений компилятора в Eclipse, для большинства из которых установлено значение «Ошибка», для многих - «Предупреждение», а для большинства - «Игнорировать».

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

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

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

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

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

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

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

Да, это хорошо, если у всех разработчиков есть один стиль кода.

Разработайте форматы стилей кода и импортируйте их для всех разработчиков.

Это поможет, когда мы создадим mergingкод для системы контроля версий.

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

1. общий взгляд на код действительно может помочь сделать код более читабельным, но также может ухудшить ситуацию, если он выглядит неправильно. _hUngarian_lpfstr нотация является ярким примером :)
2. Я видел «стандарты кода», обеспечивающие количество пробелов между блоками комментариев, алфавитный порядок имен методов и прочую чепуху. Не делай этого.
3. У разных языков разные стандарты, к которым привыкли люди, имеющие опыт их использования. Некоторые даже предписывают эти стандарты (например, Python, Cobol, Visual Studio автоматически устанавливают соглашения о стиле C ++, в то время как Java использует стиль C по соглашению и т. Д. И т. Д.).
4. Никогда не меняйте существующий код ради его изменения, вы только таким образом вводите новые проблемы. А это означает, что разделы кода, а также целые исходные файлы. Поэтому не нужно переформатировать существующий код, когда кто-то изменяет одну строку в файле из 1000 строк.
5. Опытные программисты могут быть намного более продуктивными, если им не придется вдумчиво думать, будет ли то, что они пишут, «правильным» для системы автоматического утверждения или для рецензента. У них также будет привычка писать чистый код просто потому, что это работает, даже если между их естественными стилями есть небольшие различия.

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

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

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

• Oracle опубликовала ряд соглашений для Java, которые являются стандартом де-факто.
  • Их использование должно помочь вам избежать споров о том, какому стилю следовать.
  • Многие публичные библиотеки и проекты с открытым исходным кодом, как правило, используют эти соглашения, поэтому, когда вам нужно взглянуть на них, форматирование должно быть знакомым.
  • Форматировщик Eclipse имеет встроенные правила, соответствующие этим соглашениям, что также должно помочь.
• Возможно, вы захотите встроить хук в настройку управления исходным кодом, чтобы код автоматически форматировался до того, как он попадет в основную ветку.
  • Вы можете избежать сражений с особенно упрямыми программистами, которые отказываются следовать стандарту. Они могут даже использовать свое собственное форматирование во время работы, которое будет стандартизировано позже!
  • Если вы в конечном итоге используете пользовательские настройки форматирования (например, многие люди игнорируют соглашение «максимум 80 символов на строку»), вам придется вносить изменения только в одном месте.

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

(Примеры наших решений: ширина 72 символа - это слишком мало, но 120 - лучше; лучше использовать _ALLCAPS для статических финалов; хорошая реализация принудительного выхода из функции.)

Когда у нас были обзоры кода, одним из первых вопросов было: «Вы запускали его через Checkstyle?» Соблюдение стандартов кодирования было в значительной степени автоматизировано, и это отвлекло внимание от придирчивости рецензента. Было замечательно легко, когда Checkstyle выделил сигнатуру метода, щелкнул правой кнопкой мыши и изменил переменную на final. Это также может исправить отступы и скобки, чтобы код каждого человека выглядел одинаково. Отсутствует Javadoc для публичной функции? Checkstyle помечает функцию.

(Удаление запаха кода важнее, чем согласованное форматирование. Это преимущество автоматизированных инструментов.)

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

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

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

Личные предпочтения как раз и редко улучшают производство: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

Если это произойдет, преодолеть это и сделать что-то.

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

1. Машина ошибается в самое неподходящее время, и обычно, когда вы используете новую языковую функцию. Как он будет обрабатывать замыкания в Java и т. Д.? У Jalopy есть проблемы с перечислениями с функциями-членами.
2. Я думаю, что это очень разумное бремя для программиста - создавать код для компании, который выглядит как код компании. Я считаю полезным упомянуть, что именно так код отформатирован «здесь», а не как весь код должен быть отформатирован везде. Их предыдущая компания, возможно, выбрала другой путь, и это нормально. В отличие от местного языка, есть идиомы, специфичные для вашей культуры кода, которые вы хотите вывести.
3. Внедрение синтаксиса кода лучше всего делать с обзорами кода:
   1. Если форматирование важно, то это привлекает вашу организацию к проверке кода. Это огромная выгода.
   2. Если правило форматирования нарушено, человек может смотреть на него и судить лучше, чем машина, если намерение передается более четко. Это очень редко, но иногда случается.

Что касается «читабельности => производительности», структура кода (например, классы и функции с одной ответственностью) купит вас гораздо быстрее, чем форматирование кода. Форматирование кода может помочь, но разные умы по-разному разбирают утверждения - не все будут «более продуктивными». Я хотел бы удвоить структуру кода по сравнению с форматированием, потому что это также подтолкнет вас к анализу кода и заставит команду задуматься о том, как работает программа, а не о том, как выглядит один цикл.

Я не большой поклонник домино-ориентированного проектирования, но это одна из последних моделей, которая имеет ОЧЕНЬ четко сформулированную идею о том, как код должен быть структурирован, а соглашения о форматировании кода естественным образом вытекают из структурированной программы доменно-управляемого дизайна. Опять же ... Мне не нравится DDD, но это отличный пример, потому что он так хорошо определен.

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

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

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

Это, как говорится, более строгое правило "следовать кодексу, который уже существует в файле / проекте".

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

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

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

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

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

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

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

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

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

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

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

Один формат, чтобы управлять ими всеми ... это действительно оптимально?

Это как за рулем чужой машины ...

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

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

+1 ко всем упомянутым преимуществам, но ...

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

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

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

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

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

Правило 1: Дайте переменные / курсоры / объекты / процедуры / любые ЧУВСТВИТЕЛЬНЫЕ ИМЕНА. Однозначные имена, которые привносят смысл и понимание в ваш код.

Правило 2: Используйте отступы, чтобы показать структуру вашего кода.

Вот и все.

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

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

Google опубликовал статью на эту тему под названием «Поиск долгов: опыт управления техническим долгом в Google» .

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

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

Мои самые большие проблемы с концепцией

1. Если я пишу код в одном формате, и он автоматически переформатируется, какой стимул есть для изучения этого формата?
2. После этого предыдущего пункта, если вы не изучите формат, весь смысл автоформатирования (чтобы сделать код более легким для чтения и изменения) полностью теряется. Вам все еще нужно время, чтобы выяснить форматирование, когда вы читаете код, потому что вы не узнали этот формат
3. Я думаю, что для разработчика было бы очень неприятно написать один день, закрыть его и вернуться на следующий день, чтобы увидеть, что он совершенно другой. Это означает, что не только другие должны изучать ваш код, вы должны изучать ваш код.
4. Это также может способствовать ленивому кодированию. Вместо того, чтобы подталкивать разработчика к изучению формата, они могут писать в любом формате под солнцем, и это будет выглядеть автоматически так, как этого хотят все остальные. Это восходит к # 2, где вы не изучаете стиль и все еще не можете прочитать его правильно.

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

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