Java 编码标准/最佳实践 - 中断/继续标签的命名约定

发布于 2024-07-04 07:11:10 字数 215 浏览 8 评论 0原文

有时,带标签的中断或继续可以使代码更具可读性。

OUTERLOOP: for ( ;/*stuff*/; ) {
    //...lots of code

    if ( isEnough() ) break OUTERLOOP;
    //...more code
}

我想知道标签的共同约定是什么。 全部大写? 第一个上限?

Sometimes a labeled break or continue can make code a lot more readable.

OUTERLOOP: for ( ;/*stuff*/; ) {
    //...lots of code

    if ( isEnough() ) break OUTERLOOP;
    //...more code
}

I was wondering what the common convention for the labels was. All caps? first cap?

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

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

发布评论

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

评论(10

左岸枫 2024-07-11 07:11:10

Sun 的 Java 代码风格似乎更喜欢以与变量相同的方式命名标签,即首字母小写的驼峰式命名法。

Sun's Java code style seem to prefer naming labels in the same way as variables, meaning camel case with the first letter in lower case.

若有似无的小暗淡 2024-07-11 07:11:10

我不明白这个“不要使用标签”规则从何而来。 在执行重要的循环逻辑时,中断或继续的测试并不总是整齐地位于周围块的末尾。

outer_loop:
for (...) {
  //  some code
  for (...) {
    //  some code
    if (...)
      continue outer_loop;
    //  more code
  }
  //  more code
}

是的,这样的案例确实时常发生。 人们建议我用什么来代替? 像这样的布尔条件?

for (...) {
  //  some code
  boolean continueOuterLoop = false;
  for (...) {
    //  some code
    if (...) {
      continueOuterLoop = true;
      break;
    }
    //  more code
  }
  if (continueOuterLoop)
    continue;
  //  more code
}

恶心!将其重构为一种方法也不能缓解这个问题:

boolean innerLoop (...) {
  for (...) {
    //  some code
    if (...) {
      return true;
    }
    //  more code
  }
  return false;
}

for (...) {
  //  some code
  if (innerLoop(...))
    continue;
  //  more code
}

当然它更漂亮了一点,但它仍然传递了一个多余的布尔值。 如果内部循环修改了局部变量,将其重构为方法并不总是正确的解决方案。

那么为什么你们都反对标签呢? 针对上述情况,请给我一些充分的理由和实际的替代方案。

I don't understand where this "don't use labels" rule comes from. When doing non-trivial looping logic, the test to break or continue isn't always neatly at the end of the surrounding block.

outer_loop:
for (...) {
  //  some code
  for (...) {
    //  some code
    if (...)
      continue outer_loop;
    //  more code
  }
  //  more code
}

Yes, cases like this do happen all the time. What are people suggesting I use instead? A boolean condition like this?

for (...) {
  //  some code
  boolean continueOuterLoop = false;
  for (...) {
    //  some code
    if (...) {
      continueOuterLoop = true;
      break;
    }
    //  more code
  }
  if (continueOuterLoop)
    continue;
  //  more code
}

Yuck! Refactoring it as a method doesn't alleviate that either:

boolean innerLoop (...) {
  for (...) {
    //  some code
    if (...) {
      return true;
    }
    //  more code
  }
  return false;
}

for (...) {
  //  some code
  if (innerLoop(...))
    continue;
  //  more code
}

Sure it's a little prettier, but it's still passing around a superfluous boolean. And if the inner loop modified local variables, refactoring it into a method isn't always the correct solution.

So why are you all against labels? Give me some solid reasons, and practical alternatives for the above case.

紙鸢 2024-07-11 07:11:10

如果您必须使用它们,请使用大写字母,这会引起人们的注意,并将它们从被错误地解释为“类”名称中脱颖而出。 引起人们对它们的注意还有一个额外的好处,那就是吸引人们的注意力,他们会重构你的代码并删除它们。 ;)

If you have to use them use capitals, this draws attention to them and singles them out from being mistakenly interpreted as "Class" names. Drawing attention to them has the additional benefit of catching someone's eye that will come along and refactor your code and remove them. ;)

风苍溪 2024-07-11 07:11:10

惯例是完全避免标签。

使用标签来跳出循环的正当理由非常非常少。 打破是可以的,但你可以通过稍微修改你的设计来完全消除打破的需要。 在您给出的示例中,您将提取“大量代码”部分,并将它们放入具有有意义名称的单独方法中。

for ( ;/*stuff*/; ) 
{
    lotsOfCode();

    if ( !isEnough() )
    {
        moreCode();
    }
}

编辑:看到有问题的实际代码(在这里) ,我认为使用标签可能是使代码可读的最好方法。 在大多数情况下使用标签是错误的方法,在这种情况下,我认为这是可以的。

The convention is to avoid labels altogether.

There are very, very few valid reasons to use a label for breaking out of a loop. Breaking out is ok, but you can remove the need to break at all by modifying your design a little. In the example you have given, you would extract the 'Lots of code' sections and put them in individual methods with meaningful names.

for ( ;/*stuff*/; ) 
{
    lotsOfCode();

    if ( !isEnough() )
    {
        moreCode();
    }
}

Edit: having seen the actual code in question (over here), I think the use of labels is probably the best way to make the code readable. In most cases using labels is the wrong approach, in this instance, I think it is fine.

诗化ㄋ丶相逢 2024-07-11 07:11:10

我最常看到的约定是简单的驼峰式大小写,就像方法名称一样...

myLabel:

但我也看到过带有下划线

_myLabel:

或实验室前缀的标签...

labSomething:

您可能可以从其他答案中感觉到您会很难找到一个除了“不要使用标签”之外的编码标准。 我想答案是你应该使用任何对你有意义的风格,只要它是一致的。

The convention I've most seen is simply camel case, like a method name...

myLabel:

but I've also seen labels prefixed with an underscore

_myLabel:

or with lab...

labSomething:

You can probably sense though from the other answers that you'll be hard-pushed to find a coding standard that says anything other than 'Don't use labels'. The answer then I guess is that you should use whatever style makes sense to you, as long as it's consistent.

南城追梦 2024-07-11 07:11:10

wrt sadie 的代码示例

您给出了

outerloop:
for (...) {
  //  some code
  for (...) {
    //  some code
    if (...)
      continue outerloop;
    //  more code
  }
  //  more code
}

一个示例。 你说的对。 我最好的猜测是:

public void lookMumNoLabels() {
  for (...) {
    // some code
    doMoreInnerCodeLogic(...);
  }
}

private void doMoreInnerCodeLogic(...) {
   for (...) {
      // some code
      if (...) return;
   }
}

但是在某些例子中,这种重构与您正在执行的任何逻辑都不相符。

wrt sadie's code example:

You gave

outerloop:
for (...) {
  //  some code
  for (...) {
    //  some code
    if (...)
      continue outerloop;
    //  more code
  }
  //  more code
}

As an example. You make a good point. My best guess would be:

public void lookMumNoLabels() {
  for (...) {
    // some code
    doMoreInnerCodeLogic(...);
  }
}

private void doMoreInnerCodeLogic(...) {
   for (...) {
      // some code
      if (...) return;
   }
}

But there would be examples where that kind of refactoring doesn't sit correctly with whatever logic you're doing.

捶死心动 2024-07-11 07:11:10

它们是 Java 的 goto - 不确定 C# 是否有它们。 我从未在实践中使用过它们,我想不出避免它们不会产生更具可读性的代码的情况。

但如果你必须——我认为全部大写都可以。 大多数人不会使用带标签的中断,因此当他们看到代码时,大写字母会跳到他们身上,迫使他们意识到发生了什么。

They are kind of the goto of Java - not sure if C# has them. I have never used them in practice, I can't think of a case where avoiding them wouldn't result in much more readable code.

But if you have to- I think all caps is ok. Most people won't use labelled breaks, so when they see the code, the caps will jump out at them and will force them to realise what is going on.

你丑哭了我 2024-07-11 07:11:10

我知道,我不应该使用标签。

但假设,我有一些代码,可以从标记的中断中获得很多可读性,我如何格式化它们。

莫,你的前提是错误的。
问题不应该是“我如何格式化它们?”

您的问题应该是“我的代码在循环内包含大量逻辑 - 如何使其更具可读性?”

这个问题的答案是将代码移动到单独的、命名良好的函数中。 那么你根本不需要标记中断。

I know, I should not use labels.

But just assume, I have some code, that could gain a lot in readability from labeled breaks, how do I format them.

Mo, your premise is wrong.
The question shouldn't be 'how do I format them?'

Your question should be 'I have code that has a large amount of logic inside loops - how do I make it more readable?'

The answer to that question is to move the code into individual, well named functions. Then you don't need to label the breaks at all.

掩耳倾听 2024-07-11 07:11:10

约定/最佳实践仍然是根本不使用它们并重构代码,以便使用 extract 作为方法更具可读性。

The convetion/best practise would still be not to use them at all and to refactor the code so that is more readable using extract as method.

野鹿林 2024-07-11 07:11:10

由于标签很少有用,因此似乎没有明确的约定。 Java 语言规范有一个带有标签的示例,它们位于 non_cap 中。

但由于它们如此罕见,我认为最好三思而后行,它们是否真的是正确的工具。

如果它们是正确的工具,请将它们全部设置为大写,以便其他开发人员(或稍后您自己)立即意识到它们是不寻常的。 (正如克雷格已经指出的)

As labels are so rarely useful, it appears, that there is no clear convention. The Java language specification has one example with labels and they are in non_cap.

But since they are so rare, in my opinion it is best, to think twice whether they are really the right tool.

And if they are the right tool, make them all caps so that other developers (or yourself later on) realize them as something unusual right away. (as Craig already pointed out)

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