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

Есть ли какие-либо аргументы в пользу разработки стандарта кодирования (у нас его нет, но я пытался его создать)?

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

Удачи с этим. По моему опыту, существует небольшое количество инструментов (ноль!), Которые могут правильно переформатировать код из формата X в формат Y. Есть слишком много вещей, которые мешают. Вкладки против пробелов, многострочные операторы и т. Д. Достаточно взглянуть на реализацию стандартных библиотечных файлов C ++ в GNU. Что вы можете сделать, так это заставить вашу IDE всегда использовать пробелы вместо вкладок и просто не беспокоиться о переформатировании стороннего кода. Теперь ваш код выглядит так, как вам нравится, а внешний код выглядит так, как его написал оригинальный автор.

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

Большие вещи:

• Как я называю вещи?
• Определенные части языка запрещены?
• Нужно ли компилировать чистый код и с какими настройками компилятора?
• Должен ли код проходить определенные метрики?
• Какой вид тестирования необходим?
• Какая документация нужна, как в коде (комментарии), так и в других местах?
• Самое главное, как я могу получить отказ от стандарта?

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

Стандарты кодирования могут иметь непредвиденные последствия. Пример: Некоторый дурак инженера проекта будет интерпретировать «никакой магии чисел правила» означает , что if (index == 0) {...}и for (ii = 0; ii < 3; ++ii) {...}должна быть изменена if (ZERO == index) {}и for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}не смейтесь. Я видел, как это случилось. В настоящее время, когда я пишу стандарт кодирования, это «правило без магических чисел», а не правило для противодействия такой глупости.

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

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

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

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

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

Краткий ответ: Да, это отражает качество .

Что это и зачем нам это нужно?

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

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

Это главным образом продиктовано продавцом, которому принадлежит продукт. Каждый разработчик может выбирать из множества отраслевых стандартов кодирования. Некоторые компании Microsoft, Oracle и Sun Microsystems предлагают рекомендации.

Есть ли какие-либо аргументы в пользу разработки стандарта кодирования (у нас его нет, но я пытался его создать)?

Да, существуют отраслевые стандарты, которые рекомендуется использовать. Однако каждый стандарт кодирования специфичен для платформы разработки. Таким образом, стандарты кодирования в основном зависят от языка. Например, Java имеет другой стандарт, чем .NET. Например, C # .NET использует эти стандарты в этой ссылке .

Общие стандарты

Общие стандарты не имеют зависимости ни от одного языка программирования. В дополнение к предлагаемым поставщиком стандартам, также как и упомянутые отраслевые стандарты кодирования, существуют различные нотации программирования, такие как венгерская нотация или CamelCase . Я думаю, что стандарты кодирования Microsoft .NET изначально были основаны на нотациях CamelCase.

Стандарты и руководства по командному кодированию

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

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

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

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

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

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

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

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

См .: Предлагаемые Федеральное авиационное управление стандарты кодирования C и C ++

Нужно ли мне сказать больше.

Примечание: я не смог найти фактический стандарт в FAA онлайн, но я видел его.

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

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

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

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

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