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

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

Мы пытаемся сделать наше программное обеспечение более стабильным и надеемся внедрить некоторые "лучшие практики" и стандарты кодирования. Недавно мы начали серьезно относиться к этому, поскольку мы определили, что большая часть нестабильности в нашем продукте может быть связана с тем, что мы разрешили Warnings проходить без фиксации при компиляции. Мы также никогда не потрудились серьезно воспринимать утечки памяти.

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

Изменить: мы делаем довольно сложное 2D/3D графическое программное обеспечение, которое является кросс-платформенным Mac/Windows на С++.

ОТВЕТЫ

Ответ 1

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

Классическая книга по кодированию - это Code Complete 2nd edition, Стив Макконнелл. Имейте копию команды и настоятельно рекомендуйте, чтобы ваши разработчики ее приобрели (или компания получила их за них). Это удовлетворит, вероятно, 70% стилистических вопросов. CC обращается к большинству случаев разработки.

изменить:

Графическое программное обеспечение, С++, Mac/Windows.

Поскольку вы выполняете кросс-платформенную работу, я бы рекомендовал автоматизированный процесс "компиляции на проверку" для вашего Mac (10.4 (возможно), 10.5, 10.6) и Windows (XP (возможно), Vista, 7). Это гарантирует, что ваше программное обеспечение будет в наименьшей степени компилироваться, и вы знаете, когда это не так.

Ваш источник управления (который вы используете, я полагаю), должен поддерживать ветвление, и ваша стратегия ветвления может также отражать кросс-платформенность. Также выгодно иметь магистральные ветки, ветки ветвей и экспериментальные ветки. YMMV; вам, вероятно, потребуется повторить это и проконсультироваться с людьми, знакомыми с управлением конфигурацией.

Так как это С++, вы, вероятно, захотите запустить Valgrind или аналогично знать, есть ли утечка памяти. Есть некоторые статические анализаторы, которые вы можете получить: я не знаю, насколько они эффективны в современной идиоме С++. Вы также можете инвестировать в написание некоторых оберток, чтобы помочь отслеживать распределения памяти.

В отношении С++... Книги Эффективный С++, более эффективный С++ и эффективный STL (все от Scott Meyers) должны быть на чьей-то полке, а также в Modern С++ от Andrescu. Вы также можете найти книгу Липпмана на объектной модели С++, я не знаю.

НТН.

Ответ 2

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

Учитывая, что это переполнение стека, кто-то должен ссылаться на The Joel Test. Мне нравится автоматизировать как можно больше, поэтому использование Lint также является обязательным.

Ответ 7

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

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

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

Ответ 8

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

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

Лучшая книга, которую я видел для рекомендаций C/С++ в сложных проектах, - Разработка программного обеспечения большого масштаба С++. Эта книга вместе с Code Complete (которая является обязательным для чтения классикой) являются хорошими отправными точками.

Ответ 9

Эти основы хороши для большинства промышленных или командных размеров:

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

Удачи вам!

Ответ 10

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

Ответ 11

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

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

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

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

Ответ 12

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

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

Возможно, скорее, чем документ стандартов кодирования, попробуйте, чтобы команда узнала о хорошем дизайне (проще сказать, чем сделать, я знаю). Представьте, что они знают о таких вещах, как принципы 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

Ответ 13

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

Ответ 14

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

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

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

Ответ 15

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

Стандарты кодирования С++: 101 Правила, рекомендации и передовая практика Херба Саттера и Андрея Александреску (Paperback - 4 ноября 2004 г.)

Ответ 16

Если вы программируете на VB.NET, убедитесь, что для параметра Параметр Явное и Параметр Строгий установлено значение ВКЛ. Это сэкономит вам много горя, отслеживая загадочные ошибки. Они могут быть установлены на уровне проекта, чтобы вам никогда не приходилось запоминать их в своих файлах кода.

Ответ 17

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

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