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

Мне очень нравятся: MISRA Стандарт C (хотя он немного строг, но идеи верны для C ++) и Hi-Integrity http://www.codingstandard.com/HICPPCM/index.html стандарт C ++, который в значительной степени заимствован из MISRA

LDRA (инструмент статического анализа) использует эти стандарты для оценки вашей работы ( это я не использую, так как это дорого), но я могу поручиться за запуск cppcheck в качестве хорошего средства проверки статического анализа «бесплатно / бесплатно».

Если вы программируете на VB.NET, убедитесь, что для Option Explicit и Option Strict установлено значение ON. Это избавит вас от лишних хлопот, выслеживая загадочные ошибки. Их можно установить на уровне проекта, чтобы вам никогда не приходилось задавать их в файлах кода

Помимо уже рекомендованных книг, я бы также упомянул

C ++ Coding Standards: 101 Rules, Guidelines, and Best Practices by Herb Sutter and Andrei Alexandrescu (Мягкая обложка - 4 ноября 2004 г.)

Не создавайте свои собственные стандарты с нуля.

Скорее всего, есть несколько, которые уже определяют то, что вы хотите, и более полные, чем вы могли бы придумать самостоятельно . Тем не менее, не беспокойтесь слишком сильно, если вы не согласны с ним на 100% по второстепенным вопросам, вы можете поменять местами некоторые части других или назвать некоторые нарушения предупреждением, а не ошибкой - в зависимости от ваших собственных потребностей. . (например, некоторые стандарты выдают предупреждение, если длина строки превышает 80 символов, я предпочитаю не более 120 в качестве жесткого ограничения, но я бы убедился, что для этого есть веская причина - например, удобочитаемость и ясность - если было> 80).

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

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

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

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

Получите несколько книг о принципах дизайна (см. Пару рекомендаций ниже ). Может быть, попросите команду провести несколько семинаров, чтобы обсудить некоторые темы. Возможно, заставьте их коллективно написать документ о том, какие принципы могут быть важны для их проекта. Что бы ты не делал, убедитесь, что именно команда в целом решает, каковы стандарты / принципы.

http://www.amazon.co.uk/Principles-Patterns-Practices-Robert-Martin/dp/0131857258/ http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Если ваша структура требует для нормальной работы определенных правил, поместите их в свой стандарт кодирования.

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

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

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

Если вас беспокоит качество, то вы могли бы сделать одну вещь, которая на самом деле не связана с правилами: Автоматизированная сборка и тестирование. Это мне очень помогло. Как только вы обнаружите проблему, действительно полезно иметь среду, в которой вы можете написать тест для проверки проблемы. Устраните проблему, а затем легко добавьте свой тест в набор автоматических тестов, который гарантирует, что такого рода проблемы не могут вернуться, не будучи обнаруженными. Затем убедитесь, что они запускаются часто. Желательно каждый раз, когда кто-то что-то регистрирует.

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

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

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

Лучшая книга, которую я когда-либо видел по руководствам C / C ++ в сложных проектах, - это Large Scale C ++ Software Design .

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

Эти основы подходят практически для любой отрасли или команды:

1. Используйте методологию Agile (хороший пример - схватка). http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/rup_bestpractices.pdf
2. Используйте разработку через тестирование. http://www.agiledata.org/essays/tdd.html
3. Используйте согласованные стандарты кодирования. Вот пример документа: http://www.dotnetspider.com/tutorials/BestPractices.aspx
4. Ознакомьте свою команду с хорошими шаблоны проектирования. http://www.dofactory.com/Patterns/Patterns.aspx

Вы не ошибетесь с этими основами. Стройте оттуда с новыми членами команды, которые были там и сделали это. Я настоятельно рекомендую парное программирование , когда у вас появятся эти ребята в команде. Это лучший способ заразить людей передовым опытом.

Удачи вам!

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

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

Попросите всех прочитать и обсудить различные стандарты и руководства. Я (а также Страуструп) предлагаю стандарты кодирования Joint Strike Fighter . Попросите своих разработчиков классифицировать содержащиеся в нем руководящие принципы среди

• Уже выполнены
• Можно легко выполнить (несколько изменений по сравнению с текущими условиями)
• Следует работать над старым кодом и следовать в новой разработке
• Не стоит

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

Разработка через тестирование . TDD помогает выявлять логические ошибки на этапе разработки.

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

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

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

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