命名块来限制变量范围：好主意？ [英] Named blocks to limit variable scope: good idea?

问题描述

多年来，我一直使用命名块来限制临时变量的范围。我从来没有见过这样做在其他地方，这让我想知道这是一个坏主意。特别是因为Eclipse IDE默认将这些标记为警告。

我已经在我自己的代码中使用了这个效果。但是，由于它是非习惯的，当好的程序员不信任它，当他们看到它，我真的有两种方法从这里：

1. 避免这样做，或


2. 宣传它，希望它会成为一个成语。

示例（在较大的方法中）：

  final Date nextTuesday; 
 initNextTuesday：{
 GregorianCalendar cal = new GregorianCalendar（）; 
 ... //约5-10行设置日历字段
 nextTuesday = cal.getTime（）; 
} 
  

这里我使用GregorianCalendar只是初始化一个日期，以确保我不会不小心重复使用它。

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

很多人评论说最好直接使用小方法。我同意这应该是你的第一本能。但是，可能有几个缓解因素：

• 为了甚至考虑一个命名块，代码应该是简短的一次性代码


• 命名块是一种快速组织超大方法的方法，无需创建一个具有十几个参数的一次性方法。这是特别真实的，当一个类是流量，并且输入可能从版本变化。


• 创建一个新的方法鼓励它的重用，这可能是不明智的，如果使用案例不完善。


• 特别是对于单元测试，你可能需要为一次性断言定义十几个不同的对象，它们只是足够的不同，你不能（还）找到一种方法将它们合并到少数方法，也不能想出一种方法来区分它们与不是一英里长的名称。

使用命名范围的优点：

1. 临时变量


2. 有限范围向垃圾回收器和JIT编译器提供有关程序员意图的更多信息


3. 块名称提供对代码块的注释，比开放式注释更容易阅读


4. 使得更容易将大型方法中的代码重构为小方法，反之亦然，因为命名块比非结构化代码更容易分离。

缺点：

不习惯：使用命名块（即除了我之外的所有人）认为它是buggy，因为他们不能找到引用块名称。 （就像Eclipse一样。）成为惯用的东西是一场艰苦的战斗。

它可以作为一个坏的编程习惯的借口， p>

• 制作庞大的整体方法，让几个小方法更易读。






注意：根据一些深思熟虑的回答，我已经广泛地编辑了这个问题。谢谢！

解决方案

我只是直接去重构更小的方法。如果一个方法足够大，它需要分解成这样，它真的需要拆分成多个方法，如果可能。





While限制范围很好，这不是真正的命名块是为了。它是unidiomatic，这是很少是一件好事。




For years, I've been using named blocks to limit the scope of temporary variables. I've never seen this done anywhere else, which makes me wonder if this is a bad idea. Especially since the Eclipse IDE flags these as warnings by default.

I've used this to good effect, I think, in my own code. But since it is un-idiomatic to the point where good programmers will distrust it when they see it, I really have two ways to go from here:

1. avoid doing it, or
2. promote it, with the hope that it will become an idiom.

Example (within a larger method):

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

Here I'm using a GregorianCalendar just to initialize a date, and I want to make sure that I don't accidentally reuse it.

Some people have commented that you don't actually need to name the block. While that's true, a raw block looks even more like a bug, as the intent is unclear. Furthermore, naming something encourages you to think about the intention of the block. The goal here is to identify distinct sections of code, not to give every temporary variable its own scope.

Many people have commented that it's best to go straight to small methods. I agree that this should be your first instinct. However, there may be several mitigating factors:

• To even consider a named block, the code should be short, one-off code that will never be called elsewhere.
• A named block is a quick way to organize an oversized method without creating a one-off method with a dozen parameters. This is especially true when a class is in flux, and the inputs are likely to change from version to version.
• Creating a new method encourages its reuse, which may be ill-advised if the use cases aren't well-established. A named block is easier (psychologically, at least) to throw away.
• Especially for unit tests, you may need to define a dozen different objects for one-off assertions, and they are just different enough that you can't (yet) find a way to consolidate them into a small number of methods, nor can you think of a way to distinguish them with names that aren't a mile long.

Advantages of using the named scope:

1. Can't accidentally reuse temporary variables
2. Limited scope gives garbage collector and JIT compiler more information about programmer intent
3. Block name provides a comment on a block of code, which I find more readable than open-ended comments
4. Makes it easier to refactor code out of a big method into little methods, or vice versa, since the named block is easier to separate than unstructured code.

Disadvantages:

Not idiomatic: programmers who haven't seen this use of named blocks (i.e. everyone but me) assume it's buggy, since they can't find references to the block name. (Just like Eclipse does.) And getting something to become idiomatic is an uphill battle.

It can be used as an excuse for bad programming habits, such as:

• Making huge, monolithic methods where several small methods would be more legible.
• Layers of indentation too deep to read easily.

Note: I've edited this question extensively, based on some thoughtful responses. Thanks!

解决方案

I'd just go straight for refactoring into smaller methods. If a method is big enough that it needs breaking up like this, it really needs breaking up into multiple methods if at all possible.

While limiting scope is nice, this isn't really what named blocks are for. It's unidiomatic, which is very rarely a good thing.

这篇关于命名块来限制变量范围：好主意？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！