Как лучше всего снизить цикломатическую сложность при проверке данных?

Прямо сейчас я работаю над веб-приложением, которое получает значительный объем данных из базы данных, которая может возвращать нулевые результаты. При прохождении цикломатической сложности для приложения количество функций составляет от 10 до 30. По большей части большинство функций с большими числами имеют множество строк, подобных следующим:

If Not oraData.IsDBNull(4) Then row("Field") = oraData.GetString(4)

Это подводит меня к вопросу: как лучше всего снизить эти цифры? Прямо сейчас я смотрю на то, чтобы большинство функций было ниже 10.


person rjzii    schedule 15.10.2008    source источник


Ответы (5)


Как насчет использования методов расширения.

Imports System.Runtime.CompilerServices

Module Extensions

    <Extension()> _
    Public Function TryGetString(ByVal row As IDataRecord, i As Integer) As String
        If row.IsDBNull(i) Then
            Return null
        End If
        Return row.GetString(i);
    End Function

End Module

Тогда вы можете просто написать:

row("Field") = oraData.TryGetString(4)

Это облегчает чтение и снижает цикломатическую сложность ваших функций.

person Jorge Ferreira    schedule 15.10.2008

Разложить на функции, возможно примерно так:

//Object Pascal
procedure UpdateIfNotNull( const fldName: String; fldIndex : integer );
begin
  if oraData.IsDBNull( fldIndex ) then
    row( fldName ) := oraData.GetString(fldIndex);
end;

Конечно, вы можете расширить подпись процедур, чтобы «oraData» и «row» могли передаваться в качестве параметров.

person Barry Carr    schedule 15.10.2008

Первый вопрос: почему вы "зависли" на CC? Это инструмент для оценки плотности кода, и практическое правило должно быть «не слишком большим числом сс».

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

Имейте в виду, что значения NULL предоставляют информацию и не бесполезны. Например республиканец или демократ? использование null не говорит ни о каком выборе.

person jim    schedule 15.10.2008
comment
Больше всего на свете мы стараемся обеспечить возможность сопровождения приложения в долгосрочной перспективе. Это популярное приложение, которое, вероятно, будет существовать какое-то время, поэтому важно убедиться, что оно обслуживается. Также мы стараемся сосредоточить работу только на критических функциях. - person rjzii; 15.10.2008
comment
[Продолжение] Итак, сейчас все, что является ›= 20, подвергается тщательному анализу, но проблема в том, что многие из них являются функциями-оболочками данных, которые также выполняют обработку данных. Поэтому мы пытаемся выяснить, как снизить цифры, поскольку они, скорее всего, будут изменены в будущем. - person rjzii; 15.10.2008
comment
Понятно, и я прочитал комментарии к другим ответам, и я думаю, что то, как он представлен (просто нулевая проверка), будет в этом случае совершенно хорошим исключением. Высокие значения CC nbrs для функций, которые сильно зависят от вложенных IF, являются плохими и требуют рефакторинга. У меня есть функция Case, которая работает точно так же. - person jim; 15.10.2008

Вы видели этот вопрос? Он спрашивает нечто подобное (но я думаю, что на более базовом уровне) ... но тогда это означает, что ответы здесь могут быть не очень полезными.

Я определенно согласен с другими предложениями здесь: если есть повторяющиеся утверждения, которые можно аккуратно упаковать в функции / процедуры, это может быть один из подходов, который следует использовать, если вы не просто переключаете CC. Я не уверен, что вы получили слишком много, если перейдете от одного процесса с CC 35 к трем процессам с CC 15, 10 и 10. (Это неплохой первый шаг, но в идеале вы сможете чтобы упростить что-то в большем объеме, чтобы уменьшить общую CC в этой области вашей системы.)

person Dave DuPlantis    schedule 15.10.2008

Можно преобразовать if в отдельную служебную функцию, чтобы уменьшить CC. Для обработки различных типов баз данных (string, int и т. Д.) Может потребоваться ряд функций или функция, основанная на различении типов.

Тем не менее, я бы сказал, что любое решение приведет к менее удобочитаемому или удобочитаемому коду (то есть вы можете ухудшить другие показатели!) И, поскольку QA позволит ему пройти в соответствии с этим обоснованием.

person Tom Carter    schedule 15.10.2008
comment
По большей части я против использования множества функций по тем же причинам, что и вы. В зависимости от полученных отзывов я мог бы просто отметить функции, которые нужно дважды проверить, чтобы убедиться, что сложность связана с базой данных, а затем просто убедиться, что они хорошо протестированы. - person rjzii; 15.10.2008