Есть ли у вас какие-либо полезные советы / ссылки на набор стандартов кодирования или передовые практики для подражания? - PullRequest
8 голосов
/ 20 февраля 2009

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

например. http://msdn.microsoft.com/en-us/library/ms229042.aspx

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

Спасибо за ваше время.

РЕДАКТИРОВАТЬ: Как мы знаем, есть много связанных статей на эту тему, но C # стандарт кодирования / лучшие практики в SO имеет некоторые очень полезные ссылки, которые стоит посетить. (Ознакомьтесь с 2 ссылками на руководства по .NET / C # от ESV - Accepted Answer)

Ответы [ 20 ]

12 голосов
/ 20 февраля 2009

У Google есть опубликованное руководство по стилю для C ++ здесь , с которым я иногда советуюсь. Простое чтение объяснений и рассуждений, несмотря на то, согласны ли вы с некоторыми из стилей или нет, может научить вас некоторым вещам, о которых вы, возможно, даже не подумали.

8 голосов
/ 20 февраля 2009

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

Это означает:

  • Стандарты кодирования должны быть обсуждены и согласованы.
  • В документе стандартов кодирования должны быть указаны причины, лежащие в основе каждого правила.
  • Стандарты кодирования должны быть хотя бы частично основаны на надежных источниках.

Источники информации о языках в ваших тегах:

8 голосов
/ 20 февраля 2009

Мой лучший совет в отношении стандартов кодирования: не позволяйте им мешать при выполнении работы.

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

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

6 голосов
/ 20 февраля 2009

Адам Коган имеет большой набор правил на своем веб-сайте. Существуют рекомендации по кодированию, но есть и гораздо больше.

Правила Адама Когана для улучшения ...

5 голосов
/ 20 февраля 2009

Стандарты кодирования отличные. Мы использовали Стандарты кодирования Lance Hunt's C # для .NET почти без изменений

4 голосов
/ 20 февраля 2009

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

4 голосов
/ 20 февраля 2009

Некоторые комментарии к посту, предлагающие ознакомиться с рекомендациями Google C ++. Подробное обсуждение некоторых аспектов этих рекомендаций размещено по адресу comp.lang.c ++. Moderated .

Некоторые странные или противоречивые моменты включают:

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

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

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

Без комментариев, по поводу фразы ласка очень сильное соглашение .

Выполнение работы в конструкторах: делать только тривиальная инициализация в конструктор. Если это вообще возможно, используйте метод Init () для нетривиального инициализация. ... если ваш объект требует нетривиальной инициализации, рассмотреть возможность явного Init () метод и / или добавление флага члена указывает, был ли объект успешно инициализирован.

Да ... 2-фазный init для упрощения ... Что если у меня есть const поля? Это правило, вероятно, является следствием отношения к исключениям.

Использовать потоки только для регистрации

Какие потоки? IOStreams, стандартные потоки C, другие?

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

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

А как насчет присваивания или арифметических операторов для числовых вычислений и т. Д.?

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

Что? Копировать / вставить из предыдущего кода?

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

3 голосов
/ 20 февраля 2009

Для Java и других языков семейства C я рекомендую Стандарты программирования Sofware Monkey (конечно, поскольку они мои).

В общем, сделайте их простыми и приведите примеры и обоснование для каждого требования.

3 голосов
/ 20 февраля 2009

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

Стили программирования так же сложно изменить, как и привычки, и вам придется признать, что некоторые люди не будут делать свой код на 100% совместимым в 100% случаев. Стоило бы потратить ваше время на поиск (или написание собственной) программы для симпатичных принтеров и периодически запускать через нее весь ваш код для обеспечения согласованности. (Я всегда чувствовал себя неловко, когда вручную проверял изменения в исходном коде, которые состояли только из исправлений форматирования для кода других людей; я беспокоился, что другие будут называть меня придиркой.)

...