相关疑难解决方法(0)

多年来,我一直在使用命名块来限制临时变量的范围.我从未在其他任何地方看到过这种情况,这让我想知道这是不是一个坏主意.特别是因为Eclipse IDE默认将这些标记为警告.

我认为,在我自己的代码中,我已经使用了这个效果.但是,既然好的程序员在看到它时会不信任它,这是非惯用的,我真的有两种方法可以从这里开始:

1. 避免这样做,或
2. 促进它,希望它将成为一个成语.

示例(在更大的方法中):

final Date nextTuesday;
initNextTuesday: {
    GregorianCalendar cal = new GregorianCalendar();
    ... // About 5-10 lines of setting the calendar fields
    nextTuesday = cal.getTime();
}

这里我使用GregorianCalendar来初始化日期,我想确保我不会意外地重复使用它.

有些人评论说你实际上不需要命名块.虽然这是真的,但原始块看起来更像是一个bug,因为意图不明确.此外,命名的东西鼓励你思考块的意图.这里的目标是识别代码的不同部分,而不是为每个临时变量赋予自己的范围.

很多人评论说最好直接采用小方法.我同意这应该是你的第一直觉.但是,可能有几个缓解因素:

• 为了考虑一个命名块,代码应该是简短的一次性代码,永远不会在其他地方调用.
• 命名块是一种快速组织超大方法的方法,无需使用十几个参数创建一次性方法.当一个类不稳定时,尤其如此,输入可能会随版本而变化.
• 创建一种新方法可以促进其重用,如果用例不完善,这可能是不明智的.一个命名的块更容易(在心理上,至少)丢弃.
• 特别是对于单元测试,你可能需要为一次性断言定义十几个不同的对象,它们只是不同,你不能(还)找到一种方法将它们合并为少量的方法,你也不能想办法用一英里长的名字来区分它们.

使用命名范围的优点:

1. 不能无意中重用临时变量
2. 有限范围为垃圾收集器和JIT编译器提供了有关程序员意图的更多信息
3. 块名称提供了对代码块的注释,我发现它比开放式注释更具可读性
4. 使得将大型方法中的代码重构为小方法更容易,反之亦然,因为命名块比非结构化代码更容易分离.

缺点:

不是惯用的:没有看到使用命名块的程序员(即除了我之外的所有人)都认为它有问题,因为他们无法找到对块名称的引用.(就像Eclipse一样.)让事情成为惯用语是一场艰苦的战斗.

它可以作为不良编程习惯的借口,例如:

• 制作庞大的,单一的方法,其中几种小方法更易读.
• 压痕层太深,无法轻易阅读.

注意:基于一些深思熟虑的回答,我已经广泛地编辑了这个问题.谢谢!

比较这种方法:

void doStuff(String val) {
    if (val == null) {
        val = DEFAULT_VALUE;
    }

    // lots of complex processing on val
}

...对于这种方法:

void doStuff(String origVal) {
    String val = origVal;
    if (val == null) {
        val = DEFAULT_VALUE;
    }

    // lots of complex processing on val
}

对于前一种方法,Eclipse会发出警告"不应分配参数'val'".为什么？

在我看来,前者更清洁.首先,它并没有迫使我想出两个好名字val(想出一个好的名字就足够了).

(注意:假设val封闭类中没有命名的字段.)