在开关盒中装开关盒是不好的做法吗?如果是这样,有什么替代方案?如果我不需要,我真的不想使用if
/ else if
。
而不是做一些像:
if((this == 1) && (that == 1)){ //something }
else if((this == 1) && (that == 2)){ //something }
else if((this == 2) && (that == 3)){ //something }
我正在思考:
switch(this){
case 1:
switch(that){
case 1:
// something
break;
....
}
break;
....
}
这对我来说真的很不对劲。语法没有错,但在正确的练习方面是错误的。
答案 0 :(得分:7)
拥有执行许多不同功能的大量功能是不好的做法。如果你在开关盒中有一个开关盒,这表明你的功能可能太大了,你应该考虑把它分成更容易理解的小块。
但没有严格的规则;这一切都取决于确切的情况。
答案 1 :(得分:3)
我认为这是一种不好的做法。在大多数情况下,这是不可读的。
您可以将“sub”开关案例提取到方法中。
答案 2 :(得分:3)
避免遵循方法
switch(id)
{
case 1:
{
switch (subid)
{
case 4:
// nested code
}
}
case 2:
// some code
}
通过将嵌套部分移动到方法
中,更好的方法并改进代码switch(id)
{
case 1:
SubSwtich(subid);
break;
case 2:
// some code
}
function SubSwtich(int subid)
{
switch (subid)
{
case 4:
// nested code
}
}
答案 3 :(得分:1)
如果它使您的代码更难阅读,那么这是不好的做法。
你的具体例子中的情况是由你来决定的,但总的来说我可能会说这种情况。
你问了其他选择......
将部分代码提取到子功能中。例如:
case 'foo' :
myVar = 'blah';
break;
case 'bar' :
myVar = secondLevelFunction();
break;
此处,secondLevelFunction()
包含额外的switch()
语句,其中每个case
都会返回myVar
的值。
使用数组映射。例如:
var mapper = {'foo':'blah', 'bar':'bibble', etc};
//now, instead of a big switch(input) { .... } block that sets myVar
//for each option, you can just set it directly in a single line, like so:
var myVar = mapper[input];
此外,如果您正在寻找代码质量的具体衡量标准,您应该了解Cyclomatic Complexity。这是衡量函数复杂程度的指标。通过查看函数有多少“决策点”来进行测量。每个case
,if
,循环等都是“决策点”。你拥有的越多,你的功能就越复杂。
Cyclomatic Complexity与代码质量和良好的编码实践密切相关,因此如果您的函数具有较高的CC分数(如果它具有多个嵌套的switch
块,它可能会执行),那么它就是代码质量差。我上面描述的两种替代解决方案都可以为此提供帮助。我会留给你在CC上阅读更多内容。
显然,替代解决方案需要根据您的需求进行调整,但希望他们能给您一些想法。
答案 4 :(得分:0)
糟糕的做法?没有!可能是故障排除方面的潜在痛苦!了解如何将所有“选项”转变为更有条理,更常见的联系方式。甚至可以使用由发送的参数数量确定的方法重载来编写自己的函数。
看看at this SO post,看看它是否能为您提供一些想法。
答案 5 :(得分:0)
您应该根据switch语句在不同的例程中破坏您的代码,并且在例程中您也可以继续使用switch case。就像下面一样。
private void Switch(int value)
{
switch (value)
{
case 1:
SwitchNest(value);
break;
case 2:
break;
}
}
private void SwitchNest(int value)
{
switch (value)
{
case 1:
SwitchOtherMethod(value);
break;
case 2:
break;
}
}