Уменьшают ли выражения LINQ и Lambda цикломатическую сложность?

Question

Уменьшают ли выражения LINQ и Lambda цикломатическую сложность?Просто любопытно, потому что CodeRush на самом деле показывает уменьшение cc, когда анализатор VS увеличивает его.

Answer 1

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

Лично меня не особо беспокоит цикломатическая сложность, но я абсолютно уверен, что (при правильном использовании) LINQ улучшает читаемость.Это то что я Действительно заботиться :)

Answer 2

Я только что задался тем же вопросом, и на самом деле лямбда может увеличить цикломатическую сложность. Я провел тест, и предложения Where() могут значительно увеличить его.

Читабельность действительно является одним из ваших главных приоритетов.

Но мне не потребовалось много времени, чтобы заменить некоторые запросы LinQ методами Get(), которые предоставили мне те же данные и дополнительные преимущества.

---

Я включаю Fxcop в сценарии сборки/публикации, поэтому никогда не развертываю что-либо, не достигнув целевого показателя 25 для цикломатической сложности.

Это сложно, но я думаю, что оно того стоит.

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

---

мой совет: держите свою цикломатическую сложность ниже 25.это может помочь вам сделать каждый метод достаточно простым для удобного обслуживания.

Answer 3

Джон Скит довольно лаконично ответил на вопрос.Я хотел бы добавить, что, по моему опыту работы с языками высокого уровня, такими как C#, ценность измерения цикломатической сложности снижается из-за ценности, которую добавляют в разработку пакеты синтаксического сахара, такие как LINQ.

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

Например, если я помещаю условие внутри цикла foreach, оно оценивается как мой код и подсчитывается соответствующее количество путей кода.С другой стороны, если я применяю дерево функций к коллекции, которую я перебираю (например,Где(evalStr => evalStr == origStr) Я перемещаю условие за пределы цикла в код, сгенерированный компилятором.Число ветвей по-прежнему такое же, однако условные выражения не являются частью цикла, однако CC увеличивается за пределы цикла foreach со «штрафами» за использование анонимных методов (лямбда-выражений и делегатов) сверх фактического количества ветвей. .Функция Where позволяет мне предварительно обусловить повторяемую коллекцию, чтобы цикл выполнялся только в случае необходимости.

Однако код гораздо более читабелен.

Наконец, если кто-то решит, что логическое выражение, используемое внутри функции LINQ IQueryable, не нуждается в модульном тестировании, якобы потому, что если есть исключение, то это исключение более высокого порядка (т.бизнес-уровень) исключение (проверяемое неправильное значение, неправильный оператор, неправильный операнд и т. д.) в отличие от неидеального использования языка (использование переключателя вместо if, if вместо троичного и т. д.), а затем измерение цикломатическая сложность должна учитывать это:Функция Where( ) не должна увеличивать мой CC.Измерение цикломатической сложности не поможет улучшить код;во всяком случае, это искусственно усилит склонность разработчика к упрощению там, где упрощение не является необходимым или желательным.