在编码过程中,你最终会得到多少个嵌套代码块?

永远不会超过三个。作为我个人的哲学。然而,在某些情况下,你无法做得更好。一个典型的例子是:假设你必须迭代一个6索引矩阵的所有元素。这不是你的典型情况,但有时会发生。

所以,你可以重构掉最里面的三个循环。很好。..你如何称呼你重构的例程?

我会非常担心 switch -内- this (“使用switch是糟糕的OOP风格吗?”)。

很难对此设置任何具体的限制,因为有时这只是最好的方法。然而,如果你得到了嵌套那么深的东西,特别是嵌套循环有时会给出糟糕的算法,或者如果在开关内部,你通常可以抽象掉一些东西。

例如

public string TransformString(string _input)
{    
    if(!string.IsNullOrEmpty(_input))
    {
       // do work
       // etc.

       return answer;
    }

    return null;
}

public string TransformString(string _input)
{    
    if(string.IsNullOrEmpty(_input))
         return null;

    // do work
    // etc.

    return answer;
}

它有助于抑制筑巢,防止躁狂。有时最好保持嵌套版本(例如,我不喜欢在复杂的循环体中途点击“continue”关键字,因为这很容易搞砸并引入错误),但我通常更喜欢这种方法:)

我有时会在代码中发现这一点。但当我达到这一点时,我决定是时候进行重构了。重构是非常关键的,因为它允许更清晰的代码并降低代码的表面复杂性。

16

雪上加霜的是,整个混乱局面都被包裹在:

try{
  //1527 lines of code, 16 levels deep
} catch(Exception e) {
  log.error(e.getMessage());
  throw e;
} 

我拿出了六个实现公共接口的内部类、十几个私有方法和一个枚举。结果是代码行减少了500行,冗余可以忽略不计,公共方法中只有六级嵌套。

我的经验法则代码度量是:

1/3

C) 对于方法中的每一行重复代码,您应该重构的概率增加1/3

namespace MyNamespace
{
  class MyClass
  {
    static void MyMethod()
    {
      try
      {
        if(...)
        {
          for(...)
          {
          }
        }
      }
      finally
      {
      }
    }
  }
}

一种方法应该只专注于一件事。…在可能的情况下。有很多“经验法则”,有些可以在100%的时间内完成,但大多数在90%的时间内都能完成,无法涵盖所有角度。指导方针就是这样——它们不应该把你限制在你无法完成工作的程度。

运用你的常识,如果你的代码变得不可读,那说明你有太多的嵌套。

我尽可能地遵循这些指导方针:

• Curly's Law .
• 如果代码开始对我来说不可读,那么其他人也会不可读,重构它。
• 不要牺牲良好的编码标准,除非你别无选择,也就是说,你有一个最后期限,如果不偷工减料,你不可能达到。如果你必须采取这样的快捷方式,请添加注释,说明你为什么采取这种快捷方式,以便下一个开发人员可以看到你为什么这样做。

我每天都会发现这种情况,但这只是因为继承了代码库。

尽量避免嵌套,因为它会增加圈复杂度,你为什么不把它们放在一个类上,或者使用另一种策略。

我记得我大学的一位教授说:“一个函数,不应该超过7行。”

希望这有助于致以最诚挚的问候!

我称之为 “孤立的丑陋”

丑陋的

我更关心嵌套的大O复杂性 while 声明。

我们在一个大型的“业务线”应用程序中有一个代码库,其中方法中的嵌套级别可以是15或更高。在一个有这么多凹痕的方法中,很难遵循逻辑流程。

但是,历史上有一项政策是避免方法中的多重回报。但事后看来,这似乎是一个富有成效的设计决策。