У вашей компании есть стандарт кодирования? [закрыто]

31

Недавно я увидел, что Microsoft выпустила документ по стандартам кодирования ( All-In-One Code Framework Coding Standards ), и это заставило меня задуматься ... У компании, в которой я работаю, вообще нет официальных стандартов кодирования. Существует всего несколько разработчиков, и мы были вместе достаточно долго, чтобы развиться в похожие стили, и это никогда не было проблемой.

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

Вальтер
источник
Кажется, есть проблема со ссылкой (почти 6 лет) в этом вопросе. Согласно этой странице: 1code.codeplex.com , домашняя страница Microsoft All-In-One Code Framework была перенесена на blogs.msdn.com/b/onecode . Я не исследовал страницы блога MSDN, чтобы увидеть (если или), где можно получить доступ к стандарту.
Кевин Феган

Ответы:

39

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

  • Отсутствие стандартов может сделать ваш код нечитаемым.
  • Разногласия по поводу стандартов могут привести к войнам между разработчиками.
  • Видеть разные стандарты в одном классе может быть очень раздражающим.

Я большой поклонник того, что дядя Боб говорит о стандартах:

  1. Пусть они развиваются в течение первых нескольких итераций.
  2. Пусть они будут конкретными для команды, а не для конкретной компании.
  3. Не записывайте их, если можете этого избежать. Скорее пусть код будет способом, которым стандарты собраны.
  4. Не издавайте закон о хорошем дизайне. (например, не говорите людям не использовать goto)
  5. Убедитесь, что все знают, что стандарт касается общения, и ничего больше.
  6. После первых нескольких итераций соберите команду, чтобы решить.
Paddyslacker
источник
3
+1 за цитирование дяди Боба. и +1 (если бы я мог) за предложение НЕ записывать их.
Уолтер
21
Почему бы не записать их?
Fishtoaster
8
@ Fishtoaster - Идея в том, что сам код документирует стандарт. Так же как проектная документация часто не поддерживается при изменении кода, подробные документы по стандартам кодирования будут синхронизироваться с кодом по мере развития стандартов. Что мы делаем, это выбираем некоторые репрезентативные модули и используем их в качестве руководства. Стоит написать краткий вводный документ (мы используем вики и ссылку на реальный код), который показывает вам, где найти типичный код.
паддислакер
Хорошо, код-документы-стандарт имеет смысл, если вы предполагаете, что стандарт часто развивается. Это поднимает вопрос о том, почему ваш стандарт развивается, хотя. Самая большая причина, по которой я могу придумать стандарт кодирования, - это согласованность, которую вы не получите, если стандарт будет развиваться.
Fishtoaster
Если стандарт принадлежит команде, то команда должна иметь возможность развивать стандарт с течением времени. Если нет, то в итоге вы получите либо стандартную идею одного человека, либо некоторые архаичные предложения, которые в настоящее время документируются в этом вопросе: programmers.stackexchange.com/questions/1338/…
Paddyslacker
8

Я думаю, что очень важно иметь стандарт кодирования, даже если все, что он говорит, это «мы используем отступ в 3 пробела, а открытые скобки переходят на следующую строку». Несколько преимуществ:

  • Это делает чтение всей базы кода намного проще, поскольку переключение между стилями кодирования между файлами раздражает.
  • Это облегчает чтение одного файла, поскольку любой файл, обновленный двумя разработчиками с конфликтующими стилями, в конечном итоге будет смешивать эти стили. Прочитать файл, который смешивает табуляцию и пробелы (и отредактировать его позже), - боль в заднице.
  • Новым разработчикам легче использовать хороший стиль, если есть явный стандарт, а не подразумеваемый.
  • Согласованные соглашения об именах значительно упрощают поиск функций / переменных. Было ли это ArraySort или array_Sort или sortTheArray или doSortArray или ...?

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

Fishtoaster
источник
5

Я не согласен с «мы магазин X», поэтому мы одинаково форматируем наш код на всех языках.

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

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

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

Сильванаар
источник
1
+1. Мой Objective-C не похож на ВСЕ как мой PHP.
Дэн Рэй
2

У моего бывшего работодателя есть стандарт кодирования. Я тоже подумываю официально оформить документ для себя.

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

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

Джордж Мариан
источник
1

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

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

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

Wizard79
источник
3
Ой, я никогда даже не рассматривал несколько языков ... это должно быть сложно.
Уолтер
1

Имейте в виду, что это документ по стандартам кодирования, относящийся к универсальной структуре кода.

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

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

Скотт Дорман
источник
1
Да, я понимаю, что документ, на который я ссылался, специфичен для All-In-One Coding Framework, но это вопрос, возникший после его прочтения.
Уолтер
1

Стандартные обсуждения кодирования сводятся к этому:

  • Да, они вам нужны, последовательность и чистый код - это краеугольный камень хорошей разработки.
  • То, чем они являются, почти не имеет значения, пока все следуют одним и тем же стандартам.
  • Не пишите свое, вы в конечном итоге в бесконечной и мучительной дискуссии. Есть много, которые популярны.
  • Использование общедоступных стандартов (таких как MSDN ) дает независимую стороннюю организацию, с которой нельзя спорить. Если вы хотите поспорить с ними, обратитесь к пункту 2.

Если вы разрабатываете на C # в Visual Studio, тогда StyleCop - это серебряная пуля. Если вы также используете ReSharper, то плагин StyleCop for ReSharper просто великолепен.

dwynne
источник
1

Мы - магазин-буфет, поэтому мы используем соглашения по программированию.

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

Фактически, из-за дизайна blub любой программист blub может прочитать любой файл blub и понять его, потому что blub не имеет макросистемы.

Если мы программируем, скажем, на C или C ++ (мы все говорим на нескольких языках, даже если мы программируем на blub), мы используем в основном стиль blub для нового кода или для материалов с открытым исходным кодом, стандарт проекта, над которым мы работаем.

Тим Виллискрофт
источник
1

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

скоро
источник
1

Это может помочь людям, это также может помочь с инструментами:

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

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

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

JK.
источник