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

Question

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

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

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

Answer 1

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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