В какой точке настройки Stylecop прекращают быть полезными и начинают становиться раздражающими?
Я работаю в команде, где мы используем обширный ruleset в StyleCop, и я задаюсь вопросом, что является мыслями об общей точке, где такой инструмент прекращает быть полезным и запускается, становится раздражающим. Мы также используем GhostDoc, таким образом, код пронизан XML-комментариями, которые делают код намного тяжелее, чтобы считать и таким образом рассмотреть. Я не имею никакой проблемы с XML-комментариями и нахожу их очень полезными в местах, но они действительно необходимы на каждом поле и свойстве?
У нас есть замечательная цель "каждого проекта, должен иметь 0 Предупреждений при создании", но конечно эта цель должна быть против разумного в других отношениях бесценного времени StyleCop ruleset, потрачен впустую в "фиксации" причины предупреждений StyleCop.
Каковы мысли об этом?
РЕДАКТИРОВАНИЕ я теперь на самом деле задаюсь вопросом, каков аргумент в пользу инструмента как stylecop ВООБЩЕ? Почему не угробили его и позволяют разумным стандартам кодирования, и хорошие обзоры кода заботятся об остальных? Особенно в хорошей компетентной команде? Конечно, затем задача получения 0 Предупреждений на самом деле увеличила бы стоимость, поскольку все Предупреждения будут релевантны.
Я думаю, что единственное преимущество GhostDoc - это, сохраняет Вас жизненное небольшое количество секунды в записи XML-комментария с нуля. Я не думаю, что необходимо принять сгенерированный комментарий, не редактируя его - который контрпродуктивен, возможно.
Вот комбинация правила Stylecop (SA1642: ConstructorSummaryDocumentationMustBeginWithStandardText) быть встреченным GhostDoc генерировало комментарий xml - любой добавляет какое-либо значение в конце дня?
/// <summary>
/// Initializes a new instance of the <see cref="SomeCustomType"/> class.
/// </summary>
/// <param name="someParameter">The someParameter.</param>
public SomeCustomType(string someParameter)
{
}
4 ответа
Я думаю, это скорее напыщенная речь, чем вопрос, но я согласен с вами в том, что:
- чрезмерное соблюдение правил стиля - это плохо.
Хотя, очевидно, должны быть инструкции по форматированию исходного кода, чрезмерно предписывающие нерушимые правила приводят к неприятным угловым случаям. Строгое соблюдение правил во всех случаях может привести к появлению нечитабельного или запутанного кода.
Кодирование - это разновидность письма, и поэтому бонусное правило Оруэлла - «Нарушайте любое из этих правил, прежде чем говорить что-нибудь откровенно варварское» - должно применяться и к руководствам по стилю кодирования.
Я скептически отношусь к тому, что автоматическое применение стилей - это хорошая идея в команде компетентных программистов, которые могут устанавливать и понимать руководства по стилю. Автоматические ссылки полезны для обнаружения случайных ошибок, но если они применяются с строго предписывающими законами для форматирования кода, они не могут учитывать правило Оруэлла. При наличии строгого набора правил это может вынудить вас писать менее удобный в обслуживании код под видом ремонтопригодности.
Если в вашей команде работают менее компетентные кодировщики, чьи результаты - беспорядок, если не принуждать их к стилю, то принуждение может быть хорошей идеей. (Но тогда у вас, вероятно, проблемы посерьезнее!)
- автоматические комментарии - это очень плохо
Я раньше не видел GhostDoc, но на самом деле я немного шокирован.
Сам пример на их собственной первой странице:
/// <summary>
/// Determines the size of the page buffer.
/// </summary>
/// <param name="initialPageBufferSize">
/// Initial size of the page buffer.
/// </param>
/// <returns></returns>
public int determineBufferSize(int initialPageBufferSize) {
является почти каноническим примером плохого комментария, не добавляя абсолютно никакого понимания кода, который он документирует. Это абсолютно хуже, чем без комментариев.
Все схемы in-source-doc, которые следовали за Javadoc, иногда вызывают немного подозрения, поскольку они загромождают исходный код материалами, которые часто нацелены на конечных пользователей - аудиторию, совершенно отличную от тех, кто читает код. Но это абсолютные ямы. Не могу представить, кто подумал, что это хорошая идея.
StyleCop - это инструмент. Он не должен быть идеальным из коробки, и он не должен удовлетворять потребности каждого.
Лично я говорю: "Да, это важно" - потому что когда вы руководите командой разработчиков, StyleCop поможет вам убедиться, что ваши рекомендации по кодированию соблюдаются. Именно в этом и заключается его предназначение: оценивать стандарты кодирования автоматизированным, измеримым, последовательным способом. Если вы не хотите иметь возможность делать это в процессе сборки, то вы правы - это пустая трата времени.
Вы сами говорите об этом: цель нулевых предупреждений "должна соответствовать разумному набору правил StyleCop". Нет смысла запускать любой инструмент с конфигурацией, которая не соответствует вашим потребностям. Если какое-то правило "раздражает" вас, отключите его - но для кого-то другого оно может быть жизненно важным.
Что касается вашего вопроса "добавляет ли что-то из этого ценность": да. Люди недооценивают ценность согласованности. Если все ваши конструкторы имеют одинаковый стиль комментариев, если все Intellisense для свойств в вашем проекте имеют одинаковую структуру, это еще одно меньшее умственное препятствие (неважно, насколько маленькое), с которым придется иметь дело. А с инструментами, которые это автоматизируют, это требует почти нулевых усилий. На что жаловаться?
Когда код для обхода правила занимает больше времени, чем то, что вы когда-либо могли бы получить за счет сокращения обслуживания.
Как вы знаете, исправление ошибки занимает намного больше времени, чем ее написание, поэтому вы все равно можете проделать довольно много дополнительной работы, чтобы сделать код более надежным и поддерживаемым, прежде чем вы достигнете порогового значения.
Жизненно важно, чтобы код был хорошо написан и читаем/поддерживаем, но мы используем Visual Studio и автоматические помощники Resharper для форматирования кода, а также AtomineerUtils для поддержания комментариев XML документации в строго определенном и аккуратном формате.
В результате, основные правила StyleCop не имеют значения, так как наш код всегда придерживается важных правил "по умолчанию". Менее важные правила StyleCop, как правило, слишком строги для повседневного использования. (Большинство этих правил лишь незначительно улучшают качество или читабельность кода, если вообще улучшают, поэтому мы считаем затраты на их соблюдение неприемлемыми. Мы позволяем нашим программистам немного "свободы самовыражения" - пока их код легко читается другими членами команды, мы не возражаем против небольших вариаций в стиле кодирования). Поэтому после оценки StyleCop я не смог найти никакой реальной пользы в мире.
Напротив, мы считаем FXCop очень полезным, потому что проблемы, которые он выявляет, не сводятся к мелким проблемам читабельности - время от времени он обнаруживает серьезные ошибки и проблемы с производительностью.