你好，很高兴为你解答，我是一个不折不扣的程序员，平时开发当然也无法避免会使用IF|ELSE。当然也会有一些“高端代码”，怎么才能写出区别于IF|ELSE的高端代码呢？我觉得可以由一下几个方面去学习：
算法是程序的灵魂，同样的功能，用IF|ESLE可能要几千行代码，如果使用合适的算法，可能就只有几百行代码，甚至几十行，例如递归、动态规划算法等。
这是每个优秀程序员必备的优秀品质，高端代码不是凭空产生的，它有一定的积累过程。积累并不是闭门造车，而是开源的思维。总所周知，各大论坛、代码共享平台上都有一些优秀的源代码。可以根据自己的职业方向、编程语言去阅读源代码，并模仿它。
编程是一个需要动手的活，万丈高楼平地起，没有人一开始就能写出高端代码，都是一点点在坑里摸爬滚打，写一些简单代码，一步一步完善，一点一点进步的。我现在经过几个月的学习，回过头看几个月前的代码，都想去修复它。
编程需要不断学习，不断提升。什么才是高端代码，我现在写的代码一定比过去写的高端，只要不断学习，我未来写的代码，一定比现在高端。
希望我的回答能给你帮助，谢谢采纳。
评论0
加载中...
你这问题问得很奇怪。计算机程序离开了if else，那根本就不叫程序了。就像你盖房子，离不开砖头。
一个优秀的程序员并不是说要用多高级的技巧，用越简单的语句，写出越高效的程序，那才叫高手。
评论0
加载中...
对于这个问题，首先要弄明白“if else”的作用是什么，为什么会有那么多“if else”的代码逻辑；然后再来考虑如何解决这个问题。
“if else”表述的是一分为二的情况，表示一个业务逻辑只有有种状态，要么是这样，反之，就是那样。通常是应用在一些能够简单分为两种情况的环境中，在这种环境中，只有两种可能，如果不是前一种，那么就一定是后一种。这样的情况放到现实环境中，似乎听起来过于极端，也过于简单粗暴，毕竟现实环境是很复杂的；这样子的极端情况毕竟是少数。
那为什么会出现那么多“if else”的代码呢？其实，原因很简单，因为简单；
很多程序员，特别是初级，偏向于简单处理问题，并没有深入考虑过要实现的业务逻辑，简单粗暴地将问题一分为二的处理；
对语言基础知识、算法和数据结构的认识和了解不够，没有一个深厚的基础知识加持，很多基础知识基本上是来自于各种论坛，技术分享，而这些信息良莠不齐，所以导致基础知识一知半解，只知其然，不知其所以然，实现代码逻辑的时候就会以最简单的方式来处理；
时间限制，很多公司、项目给的开发时间是见很急、很仓促的；有的时候连需求都没有整理清楚就开始了，因为要快速完成任务，实现代码的时候就会按照最简单粗暴的方式来处理；
else 不到万不得已，不要轻易使用，即便使用，也要清楚的在注释中清楚、详细的说明为什么要使用；
遇到一分为二的代码逻辑时，可以考虑换种方式来处理：先在if 中使用一种情况做判断，并在其中处理完相应的代码逻辑后，返回处理结果；剩下的就是另一种情况了，这时就不用再使用“else”来处理了；
对于if - else if else这样的情况，可以考虑使用“枚举 + switch”来配合处理不同情况的代码逻辑；
作为一个技术人员，深厚的基础知识是行走IT江湖的内功心法，拥有深厚的内功，才能做到处变不惊；无论是学习新技术、新语言，还是提升自身实力，都是需要很深的基础、底层知识；因为不断学习，积累、进步就显得尤为重要。
1.语言基础、底层知识：
良好的语言基础；基础的数据类型，运算符、语法、语言的各种特性，也才能更好的使用语言来实现业务逻辑；
明确语言的边界：明确该语言能做什么、不能做什么；有何不足，不足该如何解决；有何优势，如何更好的发挥优势；
语言底层编译、解释原理：掌握源程序的编译、解释过程，才能知道如何才能写出高效、性能俱佳的代码，也能更好的实现程序优化；
2.数据结构和算法
算法是程序的灵魂，数据结构是算法的精髓；优秀的算法基础，能够帮助你写出高效率、高性能的代码；使用几千行代码才能实现的极其复杂的代码逻辑，使用算法实现后，可能只需要几百行、甚至是几十行代码，不过这就得要求你及其熟练的掌握数据结构和多种算法实现；
3.网络、通信协议
网络交互协议、通信协议、网络分层模型的学习也是非常有必要的，比如：TCP/IP，HTTP、HTTPSSSLTLS、IPFS等。
4.操作系统
无论是Windows、Mac OSX还是Linux系统，不一定都要精通，但要精通其一，在Linux系统的良好性能、优秀设计的大背景下，Linux系统是一个不错的方向，当然Windows也是可以考虑的方向；将来还有鸿蒙、方舟编译、Fuchsia等。
5.架构设计
在完成了多个项目以后，就可以开始着手整理、总结整个项目的架构设计了；刚开始可以是一个简单的小型项目，然后不断更新，迭代，要坚持下去；等项目达到一个体量之后，可以考虑分模块，分库分表的设计；然后可以考虑引进分布式部署，微服务技术。
在项目中不断更新技术，让自己的技术跟着自己的项目一起成长。
完结，希望以上回答能对你有所帮助。
评论0
加载中...
我前段时间针对某种情况下消除大量的if-else结构写了一篇头条《优雅地移除if-else/switch的应用实践》，感兴趣的话可以到我账号里查看，或者前往https://www.toutiao.com/i6803897250528363019/
评论0
加载中...
用不用 if else 这种基础语法不是区别代码厉不厉害的关键啊。
年轻人刚开始总因为代码越复杂，别人看不懂，越能说明自己的代码高级。这种想法实际上错的离谱。
什么是优秀的代码呢?
在完成需求的前提下，能把代码写的越简单越好，代码具有易读性、易扩展行，这些才是好代码的关键因素。而不是说你的代码用了一些高级牛逼的语法，就可以说你的代码牛逼。
写代码不要追求“茴字有几种写法”这类问题，而应该学学白居易写故事那样子，要把代码写成初级程序员也能看懂，这才是功力。很多有些的开源代码都做到这点，比如redis代码之类的。
代码中有if else 之类的代码是再正常不过了，不要炫技，不要追求屠龙技术。当然，如果代码中的if else同个地方出现太多，需要考虑下代码是不是有更好的写法，具体问题具体分析。
评论0
加载中...
首先题主的问题不简单，虽然看起来像是小白白可能问得问题，但是作为有多年实战经验的老程序猿突然面对这种拷问灵魂的问题也有可能手足无措，不知如何解答！
那如何才能写出比if else看着更高大上的逻辑呢？各层楼主其实已经给出解答了！这个得看应用场景，不能为写代码而写代码，关键在如何已巧妙的方式实现高性能代码！比如 多层嵌套的if else可以转换为 switch，如果多层嵌套if else中存在递归关系可以考虑编写dsl特定领域语言，如 json 、Sql 等。
其实每一门语言解析器都是有规律的if else判断！只不过在实现语言解析器时用了递归算法！楼主可以研究一下编译原理以及编译原理的实践antlr4 .
当你看完编译原理时就会明白这个世界确实存在比if else 更巧妙的代码。
评论0
加载中...
不要去过度关注if/else的层数，而要关注接口语义是否足够清晰；单纯减少if/else的层数，然后拆出一堆do_logic1, do_logic2...这样的接口是毫无帮助的。任何一个接口的执行过程都可以表示为：输入 + 内部状态 -> 输出这样的形式，我们分以下几种情况来讨论：输入、内部状态、输出都很简单，但中间逻辑复杂。比如说一个精心优化过的数值计算程序，可能需要根据输入在不同的取值范围采取不同的策略，还有很多逻辑用来处理会引发问题（比如除0）的边界值，这种情况下if/else数量多是难以避免的，根据步骤拆分出一些内部方法有一定帮助，但也不能完全解决问题。这种情况下最好的做法是写一篇详细的文档，从最原始的数学模型开始，然后表明什么情况下采取什么样的计算策略，策略如何推导，知道得到代码中使用的具体形式，然后给整个方法加上注释附上文档地址，并且在每个分支的地方加上注释指明对应到文档中哪个公式。这种情况下虽然方法很复杂，但是语义是清晰的，如果不修改实现的话理解语义就行了，如果要修改实现那么需要参考对照文档中的公式。输入过于复杂，比如输入带有一堆不同的参数，或者有各种奇怪的flag，每个flag有不同作用。这种情况下首先需要提高接口的抽象层次：如果接口有多个不同作用，需要拆分成不同接口；如果接口内部根据不同参数进不同分支，需要将这些参数和对应分支包在Adapter里，使用参数的地方改写成Adapter的接口，根据传入的Adapter类型不同进入不同的实现；如果接口内部有复杂的参数转换关系，需要改写成查找表。这种情况下的主要问题是接口本身抽象的有问题，有更清晰的抽象之后，实现也自然没有那么多if/else了。输出过于复杂，为了省事一个过程计算出了太多东西，又为了性能加了一堆flag控制是否计算之类。这种情况下需要果断将方法拆分成多个不同方法，每个方法只返回自己需要的内容。如果不同计算之间有共用的内部结果呢？如果这个内部结果计算并不形成瓶颈，只要提取出内部方法然后在不同过程中分别调用即可；如果希望避免重复计算，可以增加一个额外的cache对象作为参数，cache内容对用户不透明，用户只保证相同输入使用同一个cache对象即可，在计算中将中间结果保存到cache中，下次计算前先检查有没有已经得到的结果，就可以避免重复计算了。内部状态过于复杂。首先检查状态设置的是否合理，是不是有一些本来应该作为输入参数的东西被放到了内部状态中（比如用来隐式地在两个不同方法调用之间传递参数）？其次，这些状态分别控制哪些方面，是否可以分组然后实现到不同的StateManager里面？第三，画出状态转移图，尝试将内部状态分成单层分支，然后分别实现到on_xxx_state这样的方法里面，然后通过单层的switch或者查找表来调用。其实通常需要优化的都是整体接口抽象，而不是单个接口的实现，单个接口实现不清晰通常是因为接口实现和需求不同构造成的。
评论0
加载中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答1
回答
