Полезны ли инструменты принудительного применения стиля?

Question

Недавний вопрос о StyleCop предупредил меня об использовании инструментов для обеспечения стиля кодирования. Я был бы очень расстроен, если бы мне потребовалось запустить один из этих инструментов во время разработки. Люди действительно находят их полезными? Почему или почему нет?

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

Answer 1

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

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

Answer 2

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

В командной среде;

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

Answer 3

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

Очевидно, что обратная сторона уравнения с таким инструментом, как FxCop (или Code Analysis для других пользователей TFS), в большей степени основана на практиках, поэтому решение становится скорее техническим, чем личным и стилистическим.

Answer 4

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

В целом, переформатирование вручную также приводит к большему количеству конфликтов при проверке, если два человека работают над одним файлом.

Так что, если вы используете VCS, я бы даже рекомендовал применять правила форматирования. Применение правил стиля может привести к улучшению качества кода.

Answer 5

Ограничения на программирование или стиль форматирования могут помочь уменьшить трения в команде из более чем одного человека.

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

С уважением, Тамберг

Answer 6

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

Поскольку принудительное применение различий в стилях (например, когда следует '{'), может быть очень легко достигнуто автоматизированными инструментами, не слишком навязывая процесс разработки. Eclipse и Visual Studio имеют очень богатый набор параметров для автоматического форматирования кода на основе большого набора параметров.

Answer 7

Если стиль относится к форматированию (например, '{' должно быть в конце или в начале строки), это может быть очень раздражающим, особенно если слияния связаны и если этот стиль не строго соблюдается для всех разработчиков.

Если стиль ссылается на ' хорошая практика"(например, тело оператора' if 'должно быть заключено в открывающие и закрывающие фигурные скобки), на самом деле это может быть очень полезно.