Должна ли моя команда использовать какой-то общепризнанный стандарт кодирования в качестве основы для своего собственного?

Команда R & D, в которой я работаю, решила принять стандарт кодирования. Мы только недавно сформировались, и у нас слишком мало собственного кода и общего времени кодирования, чтобы основывать документ о стандартах / соглашениях на том, что органично развивалось в нашей команде, и на хороших примерах из нашего собственного кода и т. Д.

Теперь у каждого из нас есть некоторый опыт с прошлых рабочих мест - хотя никто из нас не в состоянии сказать: «Давайте примем этот всеобъемлющий документ, который я нашел подходящим для той работы, которую мы здесь делаем» (*). Кроме того, некоторые из нас (включая меня) имеют опыт работы только в тех местах, где нет официального стандарта кодирования, или пишут на разных языках в разных условиях (высокопроизводительная среда для еженедельных выпусков в отличие от более ориентированной на исследования работы по разработке)

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

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

Ноты:

• Мы ожидаем работать с C, C ++, OpenCL, CUDA, Python.
• Наша команда состоит из 4 человек + менеджер, и ожидается, что она вырастет до 5-6 в течение года или около того.
• В нашей компании команды почти полностью автономны и обычно вообще не взаимодействуют (даже не используя код друг друга - работа ведется над совершенно разными проектами); так что - никаких соображений по всей компании.
• Что касается инструментов, на данный момент мы знаем, что мы будем использовать Eclipse , поэтому его средство форматирования кода будет, по крайней мере, одним инструментом. Ctrl + Shift + F давно мой друг
• Когда я пишу на Java, я придерживался практики максимально строгого соблюдения Эффективной Java Блоха . Это не совсем стандарт кодирования, но вы можете назвать кирпичи, цемент и строительный раствор стандартом кодирования. Я думал о том, чтобы включить что-то подобное как часть «микса» (имея в виду, что мы не делаем Java).
• Я имею в виде стандартов кодирования в широком смысле этого слова, например , принимая предложения , сделанные в ответы на этот P.SE вопрос .
• Я нашел большой список документов по стандартам C ++ ; Может быть, я должен сделать это нашей базой.
• (*) Это не совсем так, но я не хочу усложнять этот вопрос слишком многими деталями.

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

Однозначно, ответ - да.

Стандарт из внешних источников ничем не превосходит. Посмотрите ответы в " https://softwareengineering.stackexchange.com/q/84203/53019 ", чтобы увидеть некоторые преимущества наличия стандарта. Последовательность и наличие основы для изменения имеют решающее значение с вашей точки зрения.

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

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

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

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

Приложение, вы спросили о том, "какой" вы должны использовать. Я специально не собираюсь отвечать на этот вопрос, поскольку любой ответ потенциально связан с пламенными войнами, вызванными мнением. Однако вы можете посмотреть на свою среду IDE (Eclipse) и посмотреть, какие опции она предоставляет в качестве стандартной конфигурации. Я бы также немного поискал и посмотрел, есть ли какие-нибудь проекты, которые подключаются к вашей IDE и предоставляют дополнительные варианты стандартов. Правильно или нет, эти стандарты уже заполнены для вас и могут сэкономить вашей команде часть работы по настройке для всех.

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

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

Теперь для C ++ на самом деле важнее договориться об общих идиомах и убедиться, что все понимают разумный современный стиль C ++, чем любые войны по соглашениям об именах. Вы должны начать с C ++ Coding Standards и с онлайн-ресурсов обязательно прочитайте C ++ FAQ .

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

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

Стандарт стиля кодирования касается только косметических вопросов: где размещать скобки и пробелы, как называть идентификаторы, как размещать комментарии и т. Д.

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

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

Стандарты CERT также довольно хорошо известны и более склонны к программированию на десктопах и безопасности программного обеспечения (а не безопасности). CERT имеет стандарты для C, C ++, Java и Perl, и эти стандарты бесплатны.

Я бы начал с изучения MISRA и CERT, а не случайного гаражного стандарта, найденного в Интернете.

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

Если вы не уверены, какие стандарты кодирования использовать, есть несколько очевидных идеальных вариантов. Без определенного порядка:
1. Какой стандарт уже поддерживается вашей IDE. Это, вероятно, настраивается.
2. Какой стандарт используется / рекомендован автором вашего компилятора.
3. Какой стандарт используется / рекомендован автором вашей основной структуры (если она существует).
4. Какой стандарт используется / рекомендован автором (-ами) / разработчиком (-ями) вашего языка программирования.
5. Какой стандарт используется / рекомендуется очень крупной компанией.

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

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

Взгляните на руководство Google для вдохновения.

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

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

Я считаю, что стандарты, такие как расположение и имя файла, более полезны1, чем кодовые (в конце концов, код имеет все формы и размеры, и вам все равно придется его читать), тогда как не зная, что readme.txt находится в / bin / doc / debug / release / documents - это настоящая боль (такой же дурацкий путь, но это уже другая история).

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

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