给自己布置这个题目在这里的时候, 我就知道不是一个好的题目. 并且这个也是一个持续的体会和总结.

当然, 对于一个好的代码的评判, 网上搜索可能一大推. 在多年coding后, 总结出来也会差不多.

基本上大方向的:

  1. 可读性
  2. 可维护性
  3. 可扩展性

从实际角度考虑的:

  1. 逻辑清晰
  2. 运行效率高
  3. 问题(bug)少

进一步的:

  1. 算法上有调优处理 – 可能归结为效率问题
  2. 有模式上的实现 – 认为 模式是对逻辑清晰的一种命名, 将这个事情进行固化
  3. 模块之间的解耦 – 多人开发,沟通协作上有利, 也利于编码的可读性

所以, 理解一下, 代码好坏与否, 在于两大块:

  1. 代码的沟通上
    代码作为程序的实现, 更作为程序员之间的语言, 是大家的一个工作”沟通”之地, 高效沟通是基础
  2. 代码的实际运行上
    show me the code, 代码的高效产出结果才是目的

所以, 到这里我还没有达到我本来要说的事情, 具体这些还是原则上的东西. 所以, 有没有一些具体的东西呢?

我自己简单想了一下, 也争取做一个持续的总结整理, 这里只说一些具体的代码书写习惯以及风格上的东西

多条件判断场景

上代码, 经常遇到很多个条件下的判断的问题, 存在多个符合条件下的判断

1
2
3
4
5
6
7
8
9
10
11
function whatYouWillSay(role) {

    const conditionA = ...;
    const conditionB = ...;
    const conditionC = ...;

    if (conditionA && conditionB && conditionC) {
        ...
    }

}

我的一个感觉就是非常不清晰, 别人读取这些条件判断的时候很不容易理解
我的一个感觉比好的体验是: 如果过分复杂,(将判断条件单独提出这个再说)

需要提取一些短路判断, 比如上边的判断

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
function ...(){
    if (!conditionA){
        return ...
    }

    if (!conditionB) {
        return ...
    }

    if (!conditionC) {
        return ...
    }

    //到这里的条件肯定都是满足的了, 上边的判断尽量简单明了, 让大家知道是什么意思
    //并且方法命名上也能自解释
    return ...

}

要有默认值的返回

对于一个方法, 首先要有一个判定, 我的输入和输出是什么, 然后再进行具体实现. 对于输出最好有一个默认值
所以 typescript 这里做得就比较好, 如果有声明输出, 没有显示输出的话, 经常会提示错误

1
2
3
4
5
6
7
8
function returnStr() : string {

    ...


    // 我是一个 str
    return 'defaultStr'
}

写法上尽量少的创建一些中间变量

但是如果中间变量可以让代码更清晰的话, 那就创建吧. 这里想到一个例子, 比如对数组需要做一个统计返回的处理
reducer 都可以进行实现.

例如最普通的求和

1
2
const arr = [];
const sum = arr.reduce((sum, cur)=>sum+cur, 0);

例如要去遍历一个数组, 但是需要根据数组输出一个东西 (其实类似上边的求和, 复杂了一些)

1
2
3
4
5
6
7
8
9
10
const arr = [4,5,6];

const effectYourSomething = arr.reduce((effect, item, index)=>{
    effect[item] = index
    return effect;;
}, {})

//输出
{4: 0, 5: 1, 6: 2}

总结

一种习惯或者素养, 并且是一个不断持续的过程.