都说太多if...else不好,可是有哪些优雅的处理方法,你还在写面条代码么!

简介: 都说太多if...else不好,可是有哪些优雅的处理方法,你还在写面条代码么!

都说太多if…else不好,可是有哪些优雅的处理方法,你还在写面条代码么!

在开发过程中,我们经常会遇到大量的if-else语句,特别是在处理复杂的业务逻辑时。

虽然if-else语句是实现逻辑判断的一种有效手段,但是过多的嵌套会导致代码的可读性和可维护性变差为了解决这个问题,我们需要采取一些优雅的方式去处理if-else的嵌套,使代码更加简洁、易于维护。

但是当我们业务逻辑复杂的情况下if…else像堆小山一样,反而可读性和可维护性变差

总结几个缺点:阅读困难、高维护成本、可扩展性差。这时候我们就需要优化自己的代码!

我们先来看一段if…else代码

这里 说一下业务场景三级联动回显(如有需要可以点击跳转详细三级联动) 切割后端返回的code 省市区 后端返回的是一串数字code

let codeNew = []
codeFun(310181882)
codeNew = codeFun(code){
  if (code.tostring().length == 4) {
    return codeNew  = [Number(code.tostring().substring(0, 2), code]
  }
  if (code.tostring().length == 6) {
    return codeNew  = [Number(code.tostring().substring(0, 2),Number(code.tostring().substring(0, 4), code]
  }
  if (code.tostring().length == 9) {
    return codeNew  = [Number(code.tostring().substring(0, 2),Number(code.tostring().substring(0,   4),Number(code.tostring().substring(0, 6), code]
  }
}

这串代码的问题:

1.这一大串要做的事情不明所以,让人很纳闷你为啥要这么做,至少需要一个变量声明一下

2.函数的命名和签名也有问题,codeFun是一个名词,和你主逻辑不太符合。而且函数也不够“纯”,内部修改了一个外部的codeNew

3.里面的Number转化 和 code.tostring()转化一下子就降低了代码的可读性


以上代码很长很繁琐接下来看优化后 使用switch 方法进行优化 —> 本段代码优化大佬

亿点小知识:优化代码使用到switch特性自动寻址 正常的是需要用break进行打断

let codeNew = []
codeNew = getFormCodeArray(310181882)
const getFormCodeArray= (code) => {
  const sub = (str, len) => Number(str.substring(0, len)); // 函数内部定义了一个sub的函数
  const codeStr = code.toString(); // 统一处理
  const codeLen = codeStr.length;
  let res = [sub(codeStr, 2), sub(codeStr, 4), sub(codeStr, 6), code];
  switch (codeLen) {
    case 4:
      res.pop();
    case 6:
      res.pop();
    case 9:
      res.pop();
  }
  res.push(code);
  return res;
};

以上的代码对于大多数的场景还是不适用的 当if…else过多的时候 我们可以使用枚举进行管理

这里我们模拟个场景 做个权限管理

client: 客户 : home

staff:员工 :home,page1,page2

lead :领导 :home,page2,page3, page4

director:总监 :可以查看全部

这个的重点在于 roleIds 是多权限的 或者后面需求更改我们可以很快的进行添加和删除枚举值

枚举出角色的权限

<view v-if="access.includes('home')">home</view>
<view v-if="access.includes('page1')">page1</view>
<view v-if="access.includes('page2')">page2</view>
<view v-if="access.includes('page3')">page3</view>
<view v-if="access.includes('page4')">page4</view>
const accesses = {
    client:['home']
    staff: ['home','page1', 'page2'],
    lead : ['home','page2','page3', 'page4'],
    director: ['home','page1', 'page2','page3', 'page4'],
}
export default {
data(){
  access:accesses['client']// 默认是客户
},
mounted(){
    const roleIds = ['员工','领导']
    if (roleIds.includes("员工")== "员工") {
      this.access = accesses['staff']
    }
    if (roleIds.includes("领导")== "领导") {
      this.access = accesses['lead']
    }
    if (roleIds.includes("总监")== "总监") {
      this.access = accesses['director']
    }
},
}

以上就通过枚举实现了 多角色显示不同的页面

这里我们要注意的是 不是说所有的if…else都要被替代

我们在优化和if…else代码的时候要考虑以是为了提高代码的可读性、可维护性和扩展性:

  • 简单的条件分支:如果代码中的if…else语句仅有一到两个简单的条件分支,没必要改。
  • 高度相关的逻辑分支:复杂的逻辑,如果被分解成多个独立的函数或对象,会失去逻辑的连贯性和上下文含义。

还有一些更高级的写法使用 策略模式 + 工厂模式、查找表模式、职责链模式 无论使用那种方法只要能实现最终的效果就好!

以上就是对if…else 的处理感谢大家的阅读

如碰到其他的问题 可以私下我 一起探讨学习

如果对你有所帮助还请 点赞 收藏谢谢~!

关注收藏博客 作者会持续更新…

相关文章
|
4月前
|
设计模式 程序员
故意把代码写得很烂,这样的 “防御性编程“ 可取吗?
故意把代码写得很烂,这样的 “防御性编程“ 可取吗?
|
7月前
|
数据可视化 测试技术
测试范围不清晰该咋办?
测试范围不清晰该咋办?
|
设计模式 数据库
理论篇|如何避免写出面条代码
理论篇|如何避免写出面条代码
153 0
理论篇|如何避免写出面条代码
|
缓存 前端开发 Java
支付宝二面:使用 try-catch 捕获异常会影响性能吗?大部分人都会答错!
支付宝二面:使用 try-catch 捕获异常会影响性能吗?大部分人都会答错!
159 0
支付宝二面:使用 try-catch 捕获异常会影响性能吗?大部分人都会答错!
|
数据库
我又写了一堆烂代码
“我又写了一堆烂代码!” 这句话我经常对自己说,目的是为了督促自己不断地思考所写的代码是否足够可靠。
68 0
|
Java C语言
看似无害的代码如何搞垮系统
编程就像魔法。最近遇到一个诡异的问题:添加一段看似无害的简单代码后,系统原有功能不可用了。 ## 复现演示 jdk 8 可使用如下演示代码复现这个问题。 `TaskCenter` 是一个任务框架,可添加多个任务,随后框架将执行这些任务。 `First` 任务是新增代码,看起来简单无害,且看不出对原有任务 `Count` 有何影响,但添加 `First` 任务后,其自身执行正常,原本正常的 `C
131 0
|
前端开发 Java Spring
求求你不要写满屏的 try...catch 了,这才是优雅的处理方式,真香...
求求你不要写满屏的 try...catch 了,这才是优雅的处理方式,真香...
273 0
求求你不要写满屏的 try...catch 了,这才是优雅的处理方式,真香...
|
Java 数据库连接 Spring
参数校验别再写满屏的 if/else 了,差点被劝退……(上)
参数校验别再写满屏的 if/else 了,差点被劝退…(上)
129 0
参数校验别再写满屏的 if/else 了,差点被劝退……(上)
|
Unix Apache C++
给代码写注释时有哪些讲究?
给代码写注释时有哪些讲究?
166 0
给代码写注释时有哪些讲究?
参数校验别再写满屏的 if/else 了,差点被劝退……(下)
参数校验别再写满屏的 if/else 了,差点被劝退……(下)
116 0