blocks|key|1219391|text|保留分隔符-如果稍后编辑代码时，如果分隔符已经存在，则不太可能遇到麻烦。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1219392|话虽如此，许多人(包括我)认为从函数中间返回是一种糟糕的做法。理想情况下，一个函数应该有一个入口点和一个出口点。|1219393|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Keep the breaks - you're less likely to run into trouble if/when you edit the code later if the breaks are already in place.

Having said that, it's considered by many (including me) to be bad practice to return from the middle of a function. Ideally a function should have one entry point and one exit point.

blocks|key|1219422|text|我会说删除它们并定义一个默认的:分支。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1219423|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I would say remove them and define a default: branch.

blocks|key|1219466|text|去掉它们。从case语句返回是惯用的，否则就是“无法访问的代码”噪声。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1219467|entityMap^0|6|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Remove them. It's idiomatic to return from <code>case</code> statements, and it's "unreachable code" noise otherwise.

blocks|key|1219498|text|我会把它们去掉。在我的书中，像这样的死代码应该被认为是错误，因为它会让你反复思考，并问自己“我怎么才能执行那行代码呢？”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1219499|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I would remove them. In my book, dead code like that should be considered errors because it makes you do a double-take and ask yourself "How would I ever execute that line?"

blocks|key|1219590|text|我通常会在没有它们的情况下编写代码。在国际海事组织，死代码往往表示草率和/或缺乏理解。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1219591|当然，我也会考虑这样的事情：|1219592|char+const+*rets[]+=+{"blah",+"foo",+"bar"};

return+rets[something];|code-block|syntax|javascript|1219593|编辑:即使有了编辑过的帖子，这个一般的想法也可以很好地工作：|1219594|char+const+*rets[]+=+{+"blah",+"foo",+"bar",+"bar",+"foo"};

if+((unsigned)something+<+5)
++++return+rets[something]
return+"foobar";|1219595|在某些情况下，特别是如果输入值是稀疏的(例如，1、100、1000和10000)，您需要使用稀疏数组。您可以很好地将其实现为树或映射(当然，开关在这种情况下仍然有效)。|1219596|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I'd normally write the code without them. IMO, dead code tends to indicate sloppiness and/or lack of understanding.

Of course, I'd also consider something like:

<pre><code>char const *rets[] = {"blah", "foo", "bar"};

return rets[something];
</code></pre>

Edit: even with the edited post, this general idea can work fine:

<pre><code>char const *rets[] = { "blah", "foo", "bar", "bar", "foo"};

if ((unsigned)something &lt; 5)
 return rets[something]
return "foobar";
</code></pre>

At some point, especially if the input values are sparse (e.g., 1, 100, 1000 and 10000), you want a sparse array instead. You can implement that as either a tree or a map reasonably well (though, of course, a switch still works in this case as well).

blocks|key|1219666|text|如果一个数组中有一个|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1219667|arr[0]+=+"blah"
arr[1]+=+"foo"
arr[2]+=+"bar"|code-block|syntax|javascript|1219668|和做return+arr[something];|offset|length|style|CODE|1219669|如果这与一般的实践有关，那么您应该将break语句保留在开关中。如果将来不再需要return语句，这将减少它在下一个case中失败的机会。|1219670|entityMap^0|0|0|2|M|0|I|5|14|6|1M|4|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@$I|T|J|U|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@$I|W|J|X|K|L]|$I|Y|J|Z|K|L]|$I|10|J|11|K|L]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|P|$]]

Wouldn't it be better to have an array with

<pre><code>arr[0] = "blah"
arr[1] = "foo"
arr[2] = "bar"
</code></pre>

and do <code>return arr[something];</code>?

If it's about the practice in general, you should keep the <code>break</code> statements in the switch. In the event that you don't need <code>return</code> statements in the future, it lessens the chance it will fall through to the next <code>case</code>.

blocks|key|1005351|text|我会采取完全不同的策略。不要在方法/函数中间返回。相反，只需将返回值放在局部变量中并在末尾发送它即可。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1005352|就我个人而言，我发现以下内容更具可读性：|1005353|String+result+=+"";

switch+(something)+{
case+0:
++result+=+"blah";
++break;
case+1:
++result+=+"foo";
++break;
}

return+result;|code-block|syntax|javascript|1005354|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I would take a different tack entirely. Don't RETURN in the middle of the method/function. Instead, just put the return value in a local variable and send it at the end.

Personally, I find the following to be more readable:

<pre><code>String result = "";

switch (something) {
case 0:
 result = "blah";
 break;
case 1:
 result = "foo";
 break;
}

return result;
</code></pre>

blocks|key|1219827|text|就我个人而言，我会删除返回并保留中断。我将使用switch语句为变量赋值。然后在switch语句后返回该变量。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1219828|虽然这是一个有争议的观点，但我一直认为好的设计和封装意味着一种进入和一种退出的方式。保证逻辑要容易得多，而且不会因为函数的圈复杂度而意外地遗漏清理代码。|1219829|有一个例外:如果在函数开始时--在获取任何资源之前--检测到错误的参数，那么可以提前返回。|1219830|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Personally I would remove the returns and keep the breaks. I would use the switch statement to assign a value to a variable. Then return that variable after the switch statement.

Though this is an arguable point I've always felt that good design and encapsulation means one way in and one way out. It is much easier to guarantee the logic and you don't accidentally miss cleanup code based on the cyclomatic complexity of your function.

One exception: Returning early is okay if a bad parameter is detected at the beginning of a function--before any resources are acquired.

blocks|key|1219841|text|我说把它们移走。如果你的代码太难读，为了安全起见，你需要在代码中插入断点，你应该重新考虑你的编码风格:)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1219842|此外，我一直不喜欢在switch语句中混合使用中断和返回，而是坚持使用其中的一个。|1219843|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I say remove them. If your code is so unreadable that you need to stick breaks in there 'to be on the safe side', you should reconsider your coding style :)

Also I've always prefered not to mix breaks and returns in the switch statement, but rather stick with one of them.

blocks|key|1219893|text|对于“正确性”，单入口，单出口块是一个好主意。至少在我攻读计算机科学学位时是这样的。因此，我可能会声明一个变量，在switch中为其赋值，然后在函数末尾返回一次|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1219894|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

For "correctness", single entry, single exit blocks are a good idea. At least they were when I did my computer science degree. So I would probably declare a variable, assign to it in the switch and return once at the end of the function

blocks|key|1005606|text|有意思的。大多数答案的共识似乎是冗余的break语句是不必要的杂乱。另一方面，我将switch中的break语句读作case的“结束”。不以break结尾的case代码块往往会作为潜在的bug出现在我面前。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1005607|我知道当有一个return而不是一个break时不是这样的，但这就是我的眼睛如何“阅读”开关中的案例块，所以我个人更喜欢每个case都与一个break配对。但许多编译器确实抱怨return之后的break是多余的/无法访问的，显然我似乎是少数人。|1005608|所以去掉跟在return后面的break。|1005609|注:所有这些都忽略了违反单一进入/退出规则是否是一个好主意。就这一点而言，我有一个观点，不幸的是，它会随着情况的变化而变化……|1005610|entityMap^0|J|5|1D|5|1Y|5|26|4|0|7|6|I|5|1Q|4|1Y|5|2G|6|2P|5|0|6|6|F|5|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]|$9|17|A|18|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|19|8|@$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1E|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|1F|8|@]|D|@]|E|$]]]|M|$]]

Interesting. The consensus from most of these answers seems to be that the redundant <code>break</code> statement is unnecessary clutter. On the other hand, I read the <code>break</code> statement in a switch as the 'closing' of a case. <code>case</code> blocks that don't end in a <code>break</code> tend to jump out at me as potential fall though bugs.

I know that that's not how it is when there's a <code>return</code> instead of a <code>break</code>, but that's how my eyes 'read' the case blocks in a switch, so I personally would prefer that each <code>case</code> be paired with a <code>break</code>. But many compilers do complain about the <code>break</code> after a <code>return</code> being superfluous/unreachable, and apparently I seem to be in the minority anyway.

So get rid of the <code>break</code> following a <code>return</code>.

NB: all of this is ignoring whether violating the single entry/exit rule is a good idea or not. As far as that goes, I have an opinion that unfortunately changes depending on the circumstances...

blocks|key|1005701|text|我个人倾向于丢掉Windows，可能这个习惯的一个来源是为break应用程序编写窗口过程：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1005702|LRESULT+WindowProc+(HWND+hwnd,+UINT+uMsg,+WPARAM+wParam,+LPARAM+lParam)
{
++++switch+(uMsg)
++++{
++++++++case+WM_SIZE:
++++++++++++return+sizeHandler+(...);
++++++++case+WM_DESTROY:
++++++++++++return+destroyHandler+(...);
++++++++...
++++}

++++return+DefWindowProc(hwnd,+uMsg,+wParam,+lParam);
}|code-block|syntax|javascript|1005703|我个人发现这种方法比声明每个处理程序设置的返回变量，然后在最后返回它要简单、简洁和灵活得多。考虑到这种方法，break是多余的，因此应该删除-它们没有任何有用的目的(在语法上或在视觉上)，只会使代码膨胀。|1005704|entityMap^0|T|5|0|0|1I|5|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|M|3|-4|5|6|7|V|8|@]|D|@]|E|$]]]|N|$]]

I personally tend to lose the <code>break</code>s. Possibly one source of this habit is from programming window procedures for Windows apps:

<pre><code>LRESULT WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
 switch (uMsg)
 {
 case WM_SIZE:
 return sizeHandler (...);
 case WM_DESTROY:
 return destroyHandler (...);
 ...
 }

 return DefWindowProc(hwnd, uMsg, wParam, lParam);
}
</code></pre>

I personally find this approach a lot simpler, succinct and flexible than declaring a return variable set by each handler, then returning it at the end. Given this approach, the <code>break</code>s are redundant and therefore should go - they serve no useful purpose (syntactically or IMO visually) and only bloat the code.

blocks|key|1005749|text|某一时刻的退出代码。这提供了更好的代码可读性。在两者之间添加返回语句(多个出口)将使调试变得困难。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1005750|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Exit code at one point. That provides better readability to code. Adding return statements (Multiple exits) in between will make debugging difficult .

blocks|key|1005798|text|如果你有"lookup“类型的代码，你可以将switch-case子句单独打包到一个方法中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1005799|我在一个“业余爱好”系统中有几个，我是为了好玩而开发的：|1005800|private+int+basePerCapitaIncomeRaw(int+tl)+{
++++switch+(tl)+{
++++++++case+0:+++++return+7500;
++++++++case+1:+++++return+7800;
++++++++case+2:+++++return+8100;
++++++++case+3:+++++return+8400;
++++++++case+4:+++++return+9600;
++++++++case+5:+++++return+13000;
++++++++case+6:+++++return+19000;
++++++++case+7:+++++return+25000;
++++++++case+8:+++++return+31000;
++++++++case+9:+++++return+43000;
++++++++case+10:++++return+67000;
++++++++case+11:++++return+97000;
++++++++default:++++return+130000;
++++}
}|code-block|syntax|javascript|1005801|(是的.这是GURPS空间...)|1005802|我同意其他人的观点，在大多数情况下，您应该在一个方法中避免多个返回，并且我确实认识到，这个返回可能会更好地实现为数组或其他形式。我刚刚发现switch-case-return与具有输入和输出之间1-1关系的查找表非常容易地匹配，就像上面的东西(角色扮演游戏中充满了它们，我相信它们也存在于其他“业务”中)+:D|1005803|另一方面，如果case子句更复杂，或者switch语句之后发生了一些事情，我不建议在其中使用return，而是在switch中设置一个变量，以break结尾，并在结尾返回变量的值。|1005804|(在...第三?手..。你可以随时将一个开关重构成它自己的方法...我怀疑它是否会对性能产生影响，如果现代编译器甚至可以将其识别为可以内联的东西，我也不会感到惊讶。)|1005805|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

If you have "lookup" type of code, you could package the switch-case clause in a method by itself.

I have a few of these in a "hobby" system I'm developing for fun:

<pre><code>private int basePerCapitaIncomeRaw(int tl) {
 switch (tl) {
 case 0: return 7500;
 case 1: return 7800;
 case 2: return 8100;
 case 3: return 8400;
 case 4: return 9600;
 case 5: return 13000;
 case 6: return 19000;
 case 7: return 25000;
 case 8: return 31000;
 case 9: return 43000;
 case 10: return 67000;
 case 11: return 97000;
 default: return 130000;
 }
}
</code></pre>

(Yep. That's GURPS space...)

I agree with others that you should in most cases avoid more than one return in a method, and I do recognize that this one might have been better implemented as an array or something else. I just found switch-case-return to be a pretty easy match to a lookup table with a 1-1 correlation between input and output, like the above thing (role-playing games are full of them, I am sure they exist in other "businesses" as well) :D

On the other hand, if the case-clause is more complex, or something happens after the switch-statement, I wouldn't recommend using return in it, but rather set a variable in the switch, end it with a break, and return the value of the variable in the end.

(On the ... third? hand... you can always refactor a switch into its own method... I doubt it will have an effect on performance, and it wouldn't surprise me if modern compilers could even recognize it as something that could be inlined...)

Let's say I have code in C with approximately this structure:

<pre><code>switch (something)
{
 case 0:
 return "blah";
 break;

 case 1:
 case 4:
 return "foo";
 break;

 case 2:
 case 3:
 return "bar";
 break;

 default:
 return "foobar";
 break;
}
</code></pre>

Now obviously, the <code>break</code>s are not necessary for the code to run correctly, but it sort of looks like bad practice if I don't put them there to me.

What do you think? Is it fine to remove them? Or would you keep them for increased "correctness"?

Switch statement with returns -- code correctness

假设我用C编写了这样的代码，结构大致如下：switch (something){    case 0:      return "blah";      break;    case 1:    case 4:      return "foo";      break;    case 2:    case 3:  ...

问带有返回的Switch语句--代码正确性
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问带有返回的Switch语句--代码正确性EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问带有返回的Switch语句--代码正确性
EN