У вас есть стандарты кодирования? Если да, то как они применяются?

Ответ 1

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

Несколько предложений:

• Самое главное - получить бай-ин в идею о том, что согласованность превосходит ваш личный предпочтительный стиль. Должно быть обсуждение стандарта кодирования как до, так и после его введения, но никто не должен позволять просто отказаться от него.
• Кодовые обзоры должны быть обязательными, с комментарием проверки, включая имя пользователя рецензента. Если вы используете подходящий мощный SCM, подумайте о том, чтобы не разрешать проверки, у которых нет действительного имени рецензента.
• Должен быть документ, который все знают о выделении стандартов кодирования. С достаточной детализацией вы не должны слишком много разбираться в аргументах.
• По возможности автоматизировать проверку соглашений (через Lint, CheckStyle, FXCop и т.д.), поэтому для коммиттера и рецензента легко получить возможность быстро проверить такие вещи, как упорядочение импорта/использования директив, пробелов и т.д.

Преимущества:

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

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

Ответ 2

Есть ли у вас стандарты кодирования?

Да, отличается от проекта к проекту.

Что он покрывает?

Код (класс, переменная, метод, константа), соглашение об именах и форматировании SQL

За ним следуют все?

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

И что вы делаете (если угодно), чтобы убедиться, что все следуют стандарту?

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

     

Система Visual Studio Team имеет красивую политику добавления и проверки кода, которая запрещает разработчикам проверять код, который не соответствует

Надеюсь, это поможет

Спасибо, Маулик Моди

Ответ 3

Мы используем действия Eclipse save и formatters. У нас есть предлагаемый стандарт, но никто его не применяет, поэтому есть некоторые варианты того, что на самом деле отформатировано, и как.

Это что-то неприятное (для меня), поскольку различные вариации пробелов фиксируются как обновления в хранилище SVN...

Ответ 4

StyleCop отлично справляется с внедрением методов компоновки кодов, и вы можете писать для него специальные правила, если что-то не покрывается базой правила, которые важны для вас.

Ответ 5

Я считаю, что стандарты кодирования очень важны. Нет ничего более неприятного, чем пытаться найти различия между двумя версиями файла только для того, чтобы найти, что весь файл был изменен кем-то, кто переформатировал все это. И я знаю, что кто-то скажет, что такая практика должна быть отменена, но большинство IDE имеют функцию "переформатировать файл" (например, Ctrl-K Ctrl-D в Visual Studio), что делает сохранение вашего кода намного легче.

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

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

Быстрое упоминание Code Style Enforcer (нажмите здесь), что довольно хорошо для выделения несоответствия в Visual Studio.

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

О да, я стандартная полиция кодирования:) Я просто написал простой script, чтобы периодически проверять и исправлять код (мой стандарт кодирования достаточно прост, чтобы реализовать это.) Я надеюсь, что люди получат сообщение после просмотра всех этих сообщений об очистке кода:)

Ответ 10

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

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

"Подтвердите стиль, используемый основным разработчиком"

Так что, если он хочет сделать 3 отпечатка в пространстве, сделайте это сами.

Это не идеально, поскольку это может потребовать перенастройки настроек вашего редактора, но он сохраняет мир: -)

Ответ 11

Есть ли у вас стандарты кодирования? Что он покрывает?

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

За ним следуют все? И что вы делаете (если вообще), чтобы убедиться, что все следуют стандарту?

В основном нам помогли получить командный договор и несколько легкий стандарт кодирования (менее 20 правил).

Как это соблюдается?

Мягко, у нас нет стандартного кода кодирования.

• Применение стандарта проверяется во время просмотра
• У нас есть файлы шаблонов, которые предоставляют стандартный шаблон

Ответ 12

JTest от ParaSoft подходит для Java.

Ответ 13

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

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

    static       // Scope
    void         // Type declaration 
func(

char   al,                //IN: Description of al
intl6u hash_table_size,   //IN/OUT: Description of hash_table_size
int8u  s)                 //OUT: Description of s
{
<local declarations>

        <statements>
}

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