Уменьшают ли выражения LINQ и Lambda Cyclomatic-сложность?

Question

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

Answer 1

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

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

Answer 2

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

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

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

---

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

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

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

---

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

Answer 3

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

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

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

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

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