Нужен ли вообще стандарт кодирования?

13

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

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

SomeKittens
источник
Если вы решили внедрить стандарт кодирования, подумайте о его применении во время непрерывной интеграции.
Лейф Карлсен
10
Если все члены команды будут обязаны использовать один и тот же IDE?
Кит Томпсон
10
Никакое переформатирование кода не заменит директиву типа « Не перегружайте операторы», за исключением редких особых случаев. , Если ваши стандарты кодирования в основном связаны с форматированием кода, вам нужны более качественные стандарты.
Калеб
Не все люди также используют IDE, например, я использую Acme.
Дисоко

Ответы:

33

Однако существует множество различных инструментов и сред 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) {...}не смейтесь. Я видел, как это случилось. В настоящее время, когда я пишу стандарт кодирования, это «правило без магических чисел», а не правило для противодействия такой глупости.

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

Дэвид Хаммен
источник
+1 за отличный список - сделать его моим любимым ответом. Особенно запретный код, предупреждения компилятора, тестирование и документация. Но я все еще думаю, что табуляция против пробелов и отступов важны. Кто-то еще упомянул тот кошмар, который возникает при изменении изменений в управлении исходным кодом.
ГленПетерсон
Простой способ иметь дело с вкладками и пробелами - запретить вкладки в стандарте кодирования. Простой способ обеспечить это - установить ловушку, которая либо отклоняет регистрацию, либо преобразует вкладки, используемые в качестве пробела, в пробелы. Автоматическая проверка некоторых стандартов кодирования, например, во время ночной сборки или регистрации (предпочтительно из-за почти мгновенной обратной связи), очень полезная функция. Что делать, если регистрация разрешена (или принудительно), а преобразование создает беспорядок? На это тоже есть простой ответ: обзор кода. Уродливый POS не должен пройти проверку; это даже не должно быть пересмотрено.
Дэвид Хаммен
Обратите внимание, что правило «без вкладок» (чего я избегал в своем списке, потому что мнения действительно разные) не означает, что вы не можете использовать вкладки при вводе кода. Достойный редактор может конвертировать вкладки, которые вводит программист, в пробелы. Если ваш редактор не может этого сделать, возможно, стоит подумать о переходе на лучший редактор.
Дэвид Хаммен,
Там нет аргументов. Просто сказать, что отступ / форматирование входит в список. Вкладки могут подходить для HTML или файлов, которые загружаются или анализируются во время выполнения.
ГленПетерсон
@GlenPeterson - Отступы / форматирование есть в моем списке или перед моим списком: «IMO, стандарт кодирования должен определять разумный набор приемлемых стилей отступов, но оставлять детали для авторов пакета». И да, есть исключения из правила «без вкладок». Makefiles, например.
Дэвид Хаммен
60

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

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

comingstorm
источник
1
Хороший ответ, это расширило мои знания хорошим объяснением, покрывающим вещи, о которых я даже не думал. +1
SomeKittens
Они также могут охватывать такие вещи, как работа с кроссплатформенной совместимостью, что крайне важно, если у нового разработчика нет опыта написания кроссплатформенного кода.
Velociraptors
3
Если вы считаете, что этот ответ является хорошим и отвечает на ваш вопрос, просто пометьте его как таковой.
Марктани
3
Не говоря уже о том, что массовое переформатирование может вызвать головную боль, когда вы добавляете туда еще один хороший стандарт: контроль исходного кода.
Мэтью Шарли
1
@MatthewScharley обычно вы нажимаете измененный код через форматере , а затем совершить (после того, как, может быть , один последний испытания , чтобы обеспечить форматировщик ничего не ломаются) , так только отформатированный код получить на репо
храповым урод
13

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

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

Брайан Оукли
источник
4
Diffs! Я не думал об этом.
SomeKittens
1
Да, определенно не позволяйте всем переформатировать код так, как им нравится каждый раз, когда они над ним работают. Это просто столпотворение. Даже плохой стандарт лучше этого. Если бы у меня был выбор, я бы постарался сделать то, что наиболее популярно в языке, чтобы новые разработчики могли быстро освоиться. Используйте Интернет, чтобы найти стандарт для вашего языка.
ГленПетерсон
5

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

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

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

введите описание изображения здесь

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

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

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

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

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

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

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

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

Юсубы
источник
Я думаю, что вопрос заключается в том, почему эти вещи важны. Вы описываете, что охватывает стандарт кодирования, но возникает вопрос, зачем это нужно.
Брайан Оукли
я еще не закончил свой ответ
Юсубов
Это While Notдолжно быть полностью Do Until.
Ry-
2

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

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

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

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

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

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

Дуг Т.
источник
Это хорошо для меня - на это меньше времени тратить время, особенно если все разработчики имеют лицензию Resharper и fxcop / stylecop работает на сервере сборки.
StuartLC
1
Стандарты должны быть и обычно являются кульминацией и консолидацией опыта людей. Те самые «способные люди», о которых вы говорите. Если они не правы, развивайте их, но уволить из рук - это рецепт анархии.
Андрей
@ Andrew. Эти события могут не подходить и могут просто связать вас с множеством идей, которые не
Даг Т.
1
+1 за удушение инноваций, контроль подгрупп, общие лучшие практики и политику. Просвещайте, не регулируйте!
kirk.burleson
«Нет стандарта письменного кодирования, полагайтесь на соглашение и просите совета» довольно хорошо работает в небольших группах (меньше, чем, я не знаю, 50-100?). Когда у вас есть тысячи людей, мигрирующих назад и вперед между проектами в пределах базы кода, это действительно помогает иметь письменный набор рекомендаций для кода.
Ватин
1

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

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

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

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

Гай Кодер
источник
Это прототип плохого стандарта кодирования. Это слишком долго, это поднимает религиозные проблемы, и что наиболее важно, это идет вразрез с современным программированием на C ++. Например, он исключает POD (простые старые данные), а его правила для исключений варьируются от плохих до архаичных. Плохо: пытаться поймать std :: bad_alloc - очень плохая идея. Архаика: идея Java по определению всех исключений, которые могут быть выброшены, и перехват всех исключений, вызванных вызываемыми функциями, просто не работает в C ++. Гораздо лучше написать безопасный код, основанный на концепциях гарантий исключений Дэвида Абрахамса.
Дэвид Хаммен,
1

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

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

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

любознательный
источник
1

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

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

endyourif
источник