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

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

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

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

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

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

1. Пусть они развиваются в течение первых нескольких итераций.
2. Пусть они будут конкретными для команды, а не для конкретной компании.
3. Не записывайте их, если можете этого избежать. Скорее пусть код будет способом, которым стандарты собраны.
4. Не издавайте закон о хорошем дизайне. (например, не говорите людям не использовать goto)
5. Убедитесь, что все знают, что стандарт касается общения, и ничего больше.
6. После первых нескольких итераций соберите команду, чтобы решить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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