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

发布于 2024-07-04 07:11:10 字数 215 浏览 10 评论 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?

分享到QQ

分享到微博

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

发布评论

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

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

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

回复收藏 0 原文

若有似无的小暗淡 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.

回复收藏 0 原文

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

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

回复收藏 0 原文

风苍溪 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.

回复收藏 0 原文

诗化ㄋ丶相逢 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.

回复收藏 0 原文

南城追梦 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.

回复收藏 0 原文