为什么很多程序员不用switch，而是大量的if……else if？
展开全部
答案：主要因为switch不适合业务系统的实际复杂需求，业务不断的变更迭代，一更改需求，条件的复杂度高了，switch无力处理。
switch优点
那么什么时候适合switch，它的场景是：基于单一变量的值（如枚举），这样的可读性比if条件更清晰。
switch缺点
从上面的场景来看，实在太局限，我来简单说一下它的一些缺点吧：
1. 现实的业务场景很复杂，条件不单一，一旦需求变更，维护代码相当崩溃。
2. switch经常忘记写break，估计很多人一不小心就忘记写了。如果你看过google的代码规范，你会发现，Google对switch的要求非常多。
switch的封装才更灵活
其实switch有人还在用也有一部分是 历史 原因，但是随着 科技 的发展，原有的设计以及落后了。
有些编程语言，如Python都没有switch这种语法。当然也有部分新语言Golang和Kotlin还是继承下来，但是又把switch包装了一下，去掉了令人误会的语法，这才让switch变得灵活起来了。 如果不封装，很难用。
IF语句的好处
通过上面描述的缺点也就是if语句更灵活的地方，根据业务进行逻辑条件编写，可维护性高。同时只要写的代码质量高，可读性也就会更高。
建议
现实的业务实际是很复杂的，我也不建议一定要用大量的if……else if,而是应该尽早返回来减少嵌套，这样增加了可读性以及降低维护的成本。
我个人觉得switch其实非常多余。
1 大部分场景，都是2到3个可能分支，用个if else就可以了，除非有4 个以上分支，太多else显得不好看，才考虑用switch.
2 switch限制多。switch必须是常量变量。if后面可以写任意表达式。
3用法复杂，case后面要么break,要么return,要是不写，居然还会继续执行剩下的分支，对于新手来说分分钟掉坑。
4 写法上其实也不比if else优雅简洁，switch xxx case xxxx ….
所以，switch徒增复杂性，真的不怎么实用。
如果有10000种switch的可能性，有1000000个值需要被处理，怕是你们说的这些个switch的好处就完全消失了，预期平均每次要比较5000次，1000000个值，总计要比较50亿次，不知道你们的CPU是啥主频能扛得住这个计算量，针对这种情况的终极武器还是hash，根据不同的语言，hash的value可以是匿名函数，可以是接口的不同实现，用hash来快速确定处理算法，而不是switch
作为程序员来说，我更喜欢switch的结构，更直观更容易找到相应的代码块。不过为什么很多程序员不用Switch，而是使用大量的if...else if的结构，甚至像Python已经不支持原生Switch语法了？
这个原因很简单，因为switch语法结构最后编译还是通过if...else if来完成代码的，所以从效率角度来说和if...else if一样的。但是switch对比条件比较单一，绝大多数支持switch的编程语言都支持等于比较，也就是说变量只能等于case中的条件才会执行代码块。但是现实情况中，对比条件绝大多数比单一等于运算要复杂得多，因此很多程序员就直接使用if...else if。但是if...else if的结构，后期维护起来会比较不清晰，毕竟没有Case...Break那么直观。但是添加一些注解应该还是能解决这个问题的。
所以，我现在能使用Switch的时候还是会使用switch，毕竟后期代码维护起来方便点。不过更多时候还是用if...else if。
switch只能用于简单判断，不支持表达式。
没有if else 使用方便。
从C/ C++来看，当分支较多且switch要比较的值是连续的话，执行速度远远远远快于if，因为switch是直接跳到目标代码执行的，而if则需要执行很多条语句，慢的不是一点点，一般编译器会根据分支数量和比较的值是否连续生成不同汇编代码，如果编译器判定不能提升速度的话，switch生成的汇编代码和if是一模一样的没有任何区别。
至于很多人不用switch我觉得可能是:
1.为了方便写代码，思维习惯随手就用if写了;
2.可能根本就不懂为什么要用switch吧。
相比之下Switch可以让人更宏观的去分析代码。编写代码和阅读代码需要宏观和微观两种视角，宏观看架构和数据走向，微观看语法和功能的片段。
有些朋友编码喜欢走一步看一步，越往后越发现前面留了好多坑需要后期再做进一步修正。有些朋友不把数据的分支想全面就会用很多if…else…来磊代码。
不是不想用Switch，只是因为编码时，太随性。所以想做专职的开发人员，对代码的宏观视角是必不可少的，并且编码时还要为今后的修改留有余地。
不是尽量别用，而是不合适没法用，合适得时候该用还是用。
比如说，变量i要求大于10，小于20,一条if(i>10&&i
switch优点
那么什么时候适合switch，它的场景是：基于单一变量的值（如枚举），这样的可读性比if条件更清晰。
switch缺点
从上面的场景来看，实在太局限，我来简单说一下它的一些缺点吧：
1. 现实的业务场景很复杂，条件不单一，一旦需求变更，维护代码相当崩溃。
2. switch经常忘记写break，估计很多人一不小心就忘记写了。如果你看过google的代码规范，你会发现，Google对switch的要求非常多。
switch的封装才更灵活
其实switch有人还在用也有一部分是 历史 原因，但是随着 科技 的发展，原有的设计以及落后了。
有些编程语言，如Python都没有switch这种语法。当然也有部分新语言Golang和Kotlin还是继承下来，但是又把switch包装了一下，去掉了令人误会的语法，这才让switch变得灵活起来了。 如果不封装，很难用。
IF语句的好处
通过上面描述的缺点也就是if语句更灵活的地方，根据业务进行逻辑条件编写，可维护性高。同时只要写的代码质量高，可读性也就会更高。
建议
现实的业务实际是很复杂的，我也不建议一定要用大量的if……else if,而是应该尽早返回来减少嵌套，这样增加了可读性以及降低维护的成本。
我个人觉得switch其实非常多余。
1 大部分场景，都是2到3个可能分支，用个if else就可以了，除非有4 个以上分支，太多else显得不好看，才考虑用switch.
2 switch限制多。switch必须是常量变量。if后面可以写任意表达式。
3用法复杂，case后面要么break,要么return,要是不写，居然还会继续执行剩下的分支，对于新手来说分分钟掉坑。
4 写法上其实也不比if else优雅简洁，switch xxx case xxxx ….
所以，switch徒增复杂性，真的不怎么实用。
如果有10000种switch的可能性，有1000000个值需要被处理，怕是你们说的这些个switch的好处就完全消失了，预期平均每次要比较5000次，1000000个值，总计要比较50亿次，不知道你们的CPU是啥主频能扛得住这个计算量，针对这种情况的终极武器还是hash，根据不同的语言，hash的value可以是匿名函数，可以是接口的不同实现，用hash来快速确定处理算法，而不是switch
作为程序员来说，我更喜欢switch的结构，更直观更容易找到相应的代码块。不过为什么很多程序员不用Switch，而是使用大量的if...else if的结构，甚至像Python已经不支持原生Switch语法了？
这个原因很简单，因为switch语法结构最后编译还是通过if...else if来完成代码的，所以从效率角度来说和if...else if一样的。但是switch对比条件比较单一，绝大多数支持switch的编程语言都支持等于比较，也就是说变量只能等于case中的条件才会执行代码块。但是现实情况中，对比条件绝大多数比单一等于运算要复杂得多，因此很多程序员就直接使用if...else if。但是if...else if的结构，后期维护起来会比较不清晰，毕竟没有Case...Break那么直观。但是添加一些注解应该还是能解决这个问题的。
所以，我现在能使用Switch的时候还是会使用switch，毕竟后期代码维护起来方便点。不过更多时候还是用if...else if。
switch只能用于简单判断，不支持表达式。
没有if else 使用方便。
从C/ C++来看，当分支较多且switch要比较的值是连续的话，执行速度远远远远快于if，因为switch是直接跳到目标代码执行的，而if则需要执行很多条语句，慢的不是一点点，一般编译器会根据分支数量和比较的值是否连续生成不同汇编代码，如果编译器判定不能提升速度的话，switch生成的汇编代码和if是一模一样的没有任何区别。
至于很多人不用switch我觉得可能是:
1.为了方便写代码，思维习惯随手就用if写了;
2.可能根本就不懂为什么要用switch吧。
相比之下Switch可以让人更宏观的去分析代码。编写代码和阅读代码需要宏观和微观两种视角，宏观看架构和数据走向，微观看语法和功能的片段。
有些朋友编码喜欢走一步看一步，越往后越发现前面留了好多坑需要后期再做进一步修正。有些朋友不把数据的分支想全面就会用很多if…else…来磊代码。
不是不想用Switch，只是因为编码时，太随性。所以想做专职的开发人员，对代码的宏观视角是必不可少的，并且编码时还要为今后的修改留有余地。
不是尽量别用，而是不合适没法用，合适得时候该用还是用。
比如说，变量i要求大于10，小于20,一条if(i>10&&i
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
