Каковы общепринятые правила форматирования кода?

Question

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

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

Какие общепринятые руководящие принципы форматирования кода, не зависящие от языка, вы работали с этим, чтобы максимизировать эффективность и результативность программиста в процессе пересмотра кода?

Answer 1

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

Answer 2

У меня есть несколько мыслей о некоторых понятиях, не связанных с языком:

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

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

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

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

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

Answer 3

Последовательность является ключом. Запишите руководящие принципы где-нибудь, и требуют соответствия.

Форматирование кода не стоит беспокоиться или спорить. Просто сделайте несколько правил и придерживайтесь их.

Answer 4

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

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

Answer 5

Я согласен с Джоэлом, что удобство сопровождения значительно возрастает, если у вас есть согласованность в вашей организации. Если я присоединюсь к другой команде, время нарастания будет намного меньше, если все будет выглядеть так же, как и мой текущий, потому что я могу читать код намного быстрее без "переключения внутреннего контекста", чтобы свести мою голову ", чтобы они использовали mVar вместо _var "/ etc

Answer 6

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

Мы "обязаны" именовать переменные с префиксами, которые указывают, что они есть. Итак, вы сразу узнаете, глядя на dpVarName, что это указатель на double, и что lVarName - это длинное целое число.

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