验证数据时降低圈复杂度的最佳方法是什么?

发布于 07-07 03:44 字数 1449 浏览 14 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

温柔戏命师2024-07-14 03:44:59

使用扩展方法怎么样。

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)

这可以流畅地读取并降低函数的圈复杂度。

What about using Extension Methods.

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

Then you can simply write:

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

This reads smoothly and reduces cyclomatic complexity on your functions.

心如狂蝶2024-07-14 03:44:59

分解为函数,也许是这样的:

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

当然,您可以扩展过程签名,以便“oraData”和“row”可以作为参数传递。

Decompose into functions, perhaps something like this:

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

Of course you can extend the procedures signature so that "oraData" and "row" can passed as parameters.

怎言笑2024-07-14 03:44:59

第一个问题是:你为什么“挂”上CC? 它是一个评估代码密集程度的工具,经验法则应该是“cc 数不要太高”。

它可能会命中所有这些“IF”并调出该数字 - 因此,通过调用一个包装函数来减少 if 的数量,该函数从处理 null 的结果集中提取数据,或者更改查询,使其不返回 null。

请记住,空值确实提供了信息并且并非无用。 例如共和党还是民主党? 使用 null 表示这两种选择都不是。

The first question is: Why are you "hung" up on CC ? It's a tool to evaluate how dense the code is and a rule of thumb should be "not too high of a cc number".

It's probably hitting all those "IF"s and bringing up that number - so reduce the number of ifs by calling a wrap function that extracts the data from the result set which handles the null or change the query so it doesn't return nulls.

Keep in mind that nulls do provide information and are not useless. For example Republican or Democrat ? using null says neither choice.

心的位置2024-07-14 03:44:59

您看到这个问题了吗? 他在问类似的问题(但我认为是在更基本的层面上)......但这意味着这里的答案可能没有太大帮助。

我绝对同意这里的其他建议:如果有重复的语句可以整齐地打包到函数/过程中,那么这可能是一种可以采取的方法,只要您不只是改变 CC 即可。 如果你从一个 CC 为 35 的 proc 转移到三个 CC 为 15、10 和 10 的 proc,我不确定你是否获得了太多。(这不是一个糟糕的第一步,但理想情况下你能够在更大范围内简化某些内容,以减少系统该区域的总 CC。)

Did you see this question? He's asking something similar (but I think at a more basic level) ... but then that means the answers there may not be much help here.

I would definitely agree with the other suggestions here: if there are repeated statements that can be neatly packaged into functions/procedures, that might be one approach to take, as long as you're not just shifting CC around. I'm not sure you've gained too much if you move from one proc with a CC of 35 to three procs with CCs of 15, 10, and 10. (It's not a bad first step, but ideally you'd be able to simplify something on a larger scope to reduce total CC in that area of your system.)

最偏执的依靠2024-07-14 03:44:59

可以将 if 重构为单独的实用函数以减少 CC。 可能需要许多函数或依赖于类型区分的函数来处理不同的数据库类型(字符串,整数等..)

但是,我认为任何解决方案都会导致代码的可维护性或可读性较差(即,您可能会恶化其他数据库类型)指标!)并且 QA 会根据这个理由允许它通过。

It is possible to refactor the if into a separate utility function to reduce your CC. A number of functions or a function relying on type differentiation might be required to handle the different database types ( string, int etc ..)

However, I would argue that any solution would result in less maintainable or readable code (i.e. you might worsen other metrics!) and would as QA allow it to pass according to this justification.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文