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

Question

Согласно McCall's Quality Model, Редакция продукта является одним из трех основных аспектов описания атрибутов качества программного продукта. В соответствии с перспективой пересмотра продукта, ремонтопригодность, способность найти и исправить дефект, определяется как ключевой фактор качества, который влияет на способность пересматривать программное обеспечение.

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

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

Answer 1

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

Answer 2

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

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

Answer 3

Консистенция - это ключ. Запишите инструкции где-нибудь и требуйте соответствия.

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

Answer 4

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

Answer 5

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

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

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

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

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

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

Answer 6

Один из великих стандартов у нас есть переменная «префикс». Пока я не приехал сюда, я в основном писал соло, поэтому я не беспокоился об этом.

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

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