В какой момент настройки Stylecop перестают быть полезными и начинают раздражать?

Ответ 1

Это скорее напыщенная речь, чем вопрос, я думаю, но я согласен с вами в следующем:

• правила с избыточным соблюдением правил - это плохая вещь.

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

Кодирование - это разнообразная запись, и как таковое правило Оруэлла Бонус - "Разобьте любой из этих правил раньше, чем говорить что-нибудь прямо варварское", также нужно применять к руководствам стиля кодирования.

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

Если у вас есть менее компетентные кодеры в вашей команде, чья продукция является беспорядочной, если она не форсирована, тогда принудительное исполнение может быть хорошей идеей. (Но тогда у вас, вероятно, были большие проблемы!)

• автоматические комментарии - очень плохая вещь.

Я раньше не видел 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, иногда немного подозрительны, поскольку они загромождают исходный код материалом, который часто нацелен на конечных пользователей, - совершенно другая аудитория для тех, кто читает код. Но это абсолютные ямы. Я не могу представить, кто думал, что это хорошая идея.

Ответ 2

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

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

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

Что касается вопроса "делает или добавляет стоимость": да. Люди недооценивают ценность последовательности. Если все ваши конструкторы имеют один и тот же стиль комментария, если все свойства Intellisense для вашего проекта имеют одинаковую структуру, это имеет меньшее умственное препятствие (как бы мало оно ни было). И с инструментами, которые его автоматизируют, он почти с нуля. На что жаловаться?

Ответ 3

Когда требуется больше времени, чтобы закодировать правило, чем то, что вы когда-либо могли бы получить за счет сокращения обслуживания.

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

Ответ 4

Очень важно, чтобы код был хорошо написан и читабельным/поддерживаемым, но мы используем автоматические помощники для форматирования кода Visual Studio и Resharper для нашего кода, а AtomineerUtils - для хранения комментариев документации XML в строго определенном и аккуратном формате.

В результате основные правила StyleCop не имеют значения, так как наш код всегда придерживается важных правил "по умолчанию". Менее простые правила StyleCop имеют тенденцию быть слишком строгими для повседневного использования. (Большинство из этих правил только делают крошечные, если вообще есть, улучшения качества или удобочитаемости кода, поэтому мы считаем, что стоимость их неприемлемости недопустима. Мы разрешаем нашим программистам немного "свободы выражения" - до тех пор, пока их код легко читается другими в команде, мы не против незначительных изменений в стиле кодирования). Поэтому после оценки StyleCop мне не удалось найти какую-либо реальную пользу.

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

Ответ 5

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

У меня нет проблем с комментариями XML и найти их очень полезными в местах, но действительно ли они нужны для каждого поля и свойства?

Некоторые поля и свойства настолько очевидны для всех, что им не нужны объяснения. Например, если класс Coordinate имеет свойства X, Y и Z, в комментариях нечего объяснять.

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

Здесь сочетание правила Stylecop (SA1642: ConstructorSummaryDocumentationMustBeginWithStandardText) встречается сгенерированным GhostDoc комментарием xml - добавляет ли какое-либо значение в конце дня?

Как-то. Некоторые инструменты отображают конструкторы так же, как и другие методы, и вы не можете визуально визуализировать их между двумя (если вы не помните имя класса). Комментарий XML, с другой стороны, настолько ясен, что очень легко понять, что это конструктор.

• Что-то еще? Отсутствие стандарта для конструкторов затруднит чтение кода и понимание того, что метод является конструктором в представлениях, где оба отображаются одинаково.

• Нет комментариев вообще? Это может быть решение, поскольку такой комментарий может быть легко сгенерирован из имени класса. Но это усложнит ситуацию (почему автоматическое генерирование комментария к конструкторам, а не к другим методам?). Кроме того, если вы не указали описание этого конструктора, как кто-нибудь может знать, что такое someParameter?

Наконец, чтобы ответить на ваш вопрос, никто не может сказать, что каждое правило StyleCop всегда полезно в каждом случае. Но помните, что глупость здесь - цель "каждый проект должен иметь 0 предупреждений при построении", а не самого StyleCop. Если вы опытный разработчик и пишете чистый код, нет причин не отключать некоторые правила StyleCop, по крайней мере, если вы хорошо понимаете, что они означают, почему они здесь и что будет последствием, чтобы не следовать правилу.

В нашей компании у нас есть политика использования StyleCop для каждого проекта, и если есть сотни предупреждений о крошечном проекте, то есть проблема. В то же время, , я часто сталкивался с ситуациями, когда я отключил несколько правил StyleCop для всех классов, просто потому, что он будет тратить время на их применение, и он ничего не приносит кому-либо. С другой стороны, я вообще не оценил, когда мой коллега отключил FxCop/StyleCop, чтобы иметь возможность писать имена классов, методов и свойств на французском языке (я во французской компании, которая также работает с англоязычными разработчиками), поэтому я бы сказал, что для некоторых людей оба инструмента должны быть включены каждый раз, без возможности их отключить.

Ответ 6

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

Но при добавлении StyleCop к существующему проекту, который был написан с другим стилем, вы получите сотни или тысячи или десятки тысяч нарушений каковы, по существу, произвольные правила, такие как:

• if должно следовать пробел
• Параметры функции должны отображаться в одной строке или в отдельной строке
• Одиночные комментарии должны начинаться с пробела
• Поля должны иметь пустую строку между
• Откроется открытая фигурная скобка
• имена полей не должны начинаться с символа подчеркивания или префикса
• Параметр по умолчанию не должен использоваться, вместо этого используйте перегрузки
• не префикс локальных вызовов this
• Порядок использования операторов

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

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

Если ответ "заткнуть StyleCop" - и быть честным - есть более чем один способ сделать это.

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

Следовательно, в устаревшей кодовой базе:

• Отредактируйте набор правил, чтобы отключить любые произвольные стилистические правила с более чем несколькими нарушениями. Это больше проблем, чем они того стоят: ничего плохого не произойдет, потому что проект использует символы подчеркивания для полей, но если вы случайно вызываете столкновение имен, пытаясь его исправить, возможно.
• Если есть одно или два нарушения, подумайте о том, лучше ли использовать файл подавления, чем редактировать рабочий, проверенный код, чтобы закрыть стилистическое предупреждение. Вам не нужно ставить в наборе изменений с тысячами изменений пробелов в сотнях файлов. Легко представить поведенческую разницу, когда вы думаете, что просто переформатируете блок, и легко пропустить такую ​​вещь, рассматривая измененные строки.
• Только если вы удовлетворены тем, что нарушение правила представляет ошибку, вы должны изменить код. Итак, что, если параметры не находятся на одной строке? Переформатируйте код, во что бы то ни стало, если вам нужно понять его прямо сейчас, и формат делает это тяжело. Но не просто потому, что StyleCop так говорит.
• Даже добавление документации параметров необязательно безвредно: Если вы не знаете код наизнанку, вы можете просто выпекать свои собственные заблуждения для следующего разработчика.