Switch(some case) {
case 1:
// compute something ...
return something;
break;
case 2:
// compute something ...
return something;
break;
/* some more cases ... */
case X:
// compute something ...
return something;
break;
default:
// do something
return something;
break;
}
在我看来：
假设这个switch语句是合理的，返回和中断看起来不正确或感觉不对。
休息显然是多余的，但遗漏的风格很差（或者这种风格很差？）？
我个人不这样做，但在代码库中有一些工作。不，我不会自以为是并纠正代码库。
如果您这样做，说C＃编译器会发出警告，说明中断是无法访问的代码。因此，在我的书中，返回和休息都是不好的形式。
其他人则评论了其他方面。至于在返回之后多余的中断：我会保持它们，沿着与{}相同的推理围绕单个语句，如果正文：它应该是每个程序员将那些制动器放在那里的第二天性。最好有100个这样的冗余休息，而不是一个无意中遗漏。
不，遗漏不是穷人的风格 - 包容是穷人的风格。那些是无法达成的陈述。摆脱它们。
我喜欢这样的事实：案例直接返回而不是设置一个局部变量，然后只返回到底部 - 这意味着当你正在阅读它只需要返回的代码时它非常清晰，而这就是全部。
关于切换的侧面说明：
至于在这里使用switch语句是否正确，它实际上取决于其他事情。使用多态类型是否有意义？如果你是Java，你能使用智能枚举吗？ （您可以在C＃中模仿这些，但没有那么多的支持。）
我要说这至少应该考虑不同的设计 - 但它可能是最简单的方法来做你想要的。
在我看来，我会省略'break'关键字。我个人认为这有助于提醒人们'执行已经结束！没什么好看的！'。
我会做一个小改动：
switch(some case) {
case 1:
// compute something ...
break;
case 2:
// compute something ...
break;
/* some more cases ... */
case X:
// compute something ...
break;
default:
// do something
break;
}
return something;
我不确定该代码的字面意义如何，因此其中一些观察结果可能不适用......
“案例1”如果你是真正的硬编码这样的人，我认为这是一种糟糕的风格，你应该考虑使用枚举。
如果你只是返回一些东西并且在一个子集的情况下没有其他逻辑，你可以考虑将“somethings”放在数组或字典中，并简单地通过它们的索引来解决它们而不是使用switch语句......
回报事[索引]
代码气味意味着设计问题。这只是格式化问题。我想大多数人会同意省略休息的版本是优越的。
休息是多余的。
一些经验法则，只在一个地方退出一个函数总是好的，但是因为这个规则被发明了，所以发明了Try-Catch（oop goto）。
如果你在整个应用程序中保持相同的风格，我想你可以接受交换机中的返回。
这里的代码气味是case语句中的硬编码值。
至于回报，它更多的是品味和良好判断的问题。当然，如果你的情况跨越多个页面，如果返回是在这种情况下更容易阅读，但问题是开始时的大开关。
Personnaly我更喜欢单一返回选项，因为如果你需要添加更多处理，那么重构比访问所有情况更便宜。另外，如果给别人重构，他们就不会有在每种情况下复制粘贴代码的诱惑，至少我希望如此......如果他们这样做，他们更希望我不是那些正在进行代码审查的人（对于复制粘贴明显）。
Switch语句本身就是代码味道。
按照l99057j的说法，如果您所做的只是将输入映射到常量值，那么这是一个适当的查找结构的位置，例如用于顺序输入的数组/列表或用于稀疏输入的字典/映射，不是开关声明。如果您正在计算某些内容，那么该值将是您使用输入调用的委托。