用返回语句切换语句 – 代码的正确性
比方说，我有大约这种结构的C代码：
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; } 现在很明显，代码没有必要正确运行，但是如果我不把它们放在那里，那看起来就像坏习惯。
你怎么看？ 删除它们可以吗？ 或者你会让他们增加“正确性”？
删除中断语句。 他们不需要，也许一些编译器会发出“无法访问的代码”的警告。
我会完全采取不同的方式。 不要在方法/函数中间返回。 相反，只需将返回值放在一个局部variables中，并在最后发送。
就我个人而言，我发现以下内容更具可读性：
String result = ""; switch (something) { case 0: result = "blah"; break; case 1: result = "foo"; break; } return result;
我个人会删除回报，并保持rest。 我将使用switch语句为variables赋值。 然后在switch语句之后返回该variables。
虽然这是一个有争议的观点，但我始终认为，良好的devise和封装意味着一种方法和一种方法。 保证逻辑容易得多，而且不会因为function的复杂性而意外错过清理代码。
一个例外：如果在函数的开始处检测到错误的参数 – 在获取任何资源之前，提前返回是可以的。
保持rest时间 – 如果/如果rest时间已经到位，则稍后编辑代码时，您不太可能遇到麻烦。
话虽如此，很多人（包括我）认为从function中间返回是不好的做法。 理想情况下，函数应该有一个入口点和一个出口点。
删除它们。 从case语句返回是惯用的，否则就是“无法访问的代码”。
我会删除它们。 在我的书中，像这样的死代码应该被认为是错误的，因为它会让你做一个双重的问题，问自己：“我将如何执行这个命令？
我通常会写没有他们的代码。 国际海事组织（IMO），死代码倾向于表示不合理和/或缺乏理解。
当然，我也会考虑这样的：
char const *rets[] = {"blah", "foo", "bar"}; return rets[something];
编辑：即使与编辑后，这个一般的想法可以正常工作：
char const *rets[] = { "blah", "foo", "bar", "bar", "foo"}; if ((unsigned)something < 5) return rets[something] return "foobar";
在某些时候，特别是如果input值稀疏（例如，1，100，1000和10000），则需要一个稀疏数组。 你可以把它当作一棵树或者一张地图来合理地实现（当然，在这种情况下，交换机仍然可以工作）。
我会说删除它们并定义一个默认：分支。
与arrays配合是不是更好？
arr[0] = "blah" arr[1] = "foo" arr[2] = "bar"
并return arr[something]; ？
如果是一般的做法，你应该在交换机中保留break语句。 如果您将来不需要return报表，则可以减less转入下一个case的可能性。
对于“正确性”，单个进入单个出口块是一个好主意。 至less他们是在我取得计算机科学学位的时候。 所以我可能会声明一个variables，在开关中赋值给它，并在函数结束时返回一次
你怎么看？ 删除它们可以吗？ 或者你会让他们增加“正确性”？
删除它们是好的。 使用return 正是不应使用break的情况。
我说删除它们。 如果你的代码太难以理解了，那么你需要在那里保持安全的rest，你应该重新考虑你的代码风格:)
另外，我一直都不希望在转换语句中混合使用中断和返回，而是坚持使用其中之一。
有趣。 大多数这些答案的共识似乎是多余的break陈述是不必要的混乱。 另一方面，我把交易中的break语句看作是一个case的“结束”。 不会以break结束的case ，往往会跳出来，因为潜在的错误。
我知道那并不是一个return而是一个return而不是一个break ，但这就是我的眼睛“如何阅读”交换机中的情况块，所以我个人宁愿每个case都配对break 。 但是很多编译器在return多余/无法访问之后就会抱怨这个break ，显然我似乎还是处于less数。
所以在return之后摆脱break 。
注意：所有这一切都是无视违反单一进入/退出规则是否是一个好主意。 就此而言，我有一个意见，不幸的是根据情况而变化…
我个人倾向于失去break 。 这种习惯的一个来源可能是Windows应用程序的编程窗口程序：
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); }
我个人发现这种方法比声明每个处理器设置的返回variables简单，简洁和灵活，然后在最后返回它。 鉴于这种方法， break是多余的，因此应该去 – 他们没有任何有用的目的（语法或IMO视觉），只有膨胀的代码。
我认为这个rest是有目的的。 保持程序的“意识形态”活着。 如果我们只是在没有逻辑一致性的情况下“编程”我们的代码，那么现在对您来说可能是可读的，但明天再试。 尝试向你的老板解释。 尝试在Windows 3030上运行它。
Bleah，这个想法很简单：
Switch ( Algorithm ) { case 1: { Call_911; Jump; }**break**; case 2: { Call Samantha_28; Forget; }**break**; case 3: { Call it_a_day; }**break**; Return thinkAboutIt?1:return 0; void Samantha_28(int oBed) { LONG way_from_right; SHORT Forget_is_my_job; LONG JMP_is_for_assembly; LONG assembly_I_work_for_cops; BOOL allOfTheAbove; int Elligence_says_anyways_thinkAboutIt_**break**_if_we_code_like_this_we_d_be_monkeys; } // Sometimes Programming is supposed to convey the meaning and the essence of the task at hand. It is // there to serve a purpose and to keep it alive. While you are not looking, your program is doing // its thing. Do you trust it? // This is how you can... // ---------- // **Break**; Please, take a **Break**;
/ *只是一个小问题，但。 阅读上面的内容，你有多less咖啡？ IT有时会打破系统* /
