给自己布置这个标体在这里的时候, 我就知道不是一个好的题目. 并且这个也是一个持续的体会和总结.
当然, 对于一个好的代码的评判, 网上搜索可能一大推. 在多年coding后, 总结出来也会差不多.
基本上大方向的:
- 可读性
- 可维护性
- 可扩展性
从实际角度考虑的:
- 逻辑清晰
- 运行效率高
- 问题(bug)少
进一步的:
- 算法上有调优处理 -- 可能归结为效率问题
- 有模式上的实现 -- 认为 模式是对逻辑清晰的一种命名, 将这个事情进行固化
- 模块之间的解耦 -- 多人开发,沟通协作上有利, 也利于编码的可读性
所以, 理解一下, 代码好坏与否, 在于两大块:
- 代码的沟通上
代码作为程序的实现, 更作为程序员之间的语言, 是大家的一个工作"沟通"之地, 高效沟通是基础 - 代码的实际运行上
show me the code, 代码的高效产出结果才是目的
所以, 到这里我还没有达到我表体要说的事情, 具体这些还是原则上的东西. 所以, 有没有一些具体的东西呢?
我自己简单想了一下, 也争取做一个持续的总结整理, 这里只说一些具体的代码书写习惯以及风格上的东西
多条件判断场景
上代码, 经常遇到很多个条件下的判断的问题, 存在多个符合条件下的判断
function whatYouWillSay(role) {
const conditionA = ...;
const conditionB = ...;
const conditionC = ...;
if (conditionA && conditionB && conditionC) {
...
}
}
我的一个感觉就是非常不清晰, 别人读取这些条件判断的时候很不容易理解
我的一个感觉比好的体验是: 如果过分复杂,(将判断条件单独提出这个再说)
需要提取一些短路判断, 比如上边的判断
function ...(){
if (!conditionA){
return ...
}
if (!condtionB) {
return ...
}
if (!condtionC) {
return ...
}
//到这里的条件肯定都是满足的了, 上边的判断尽量简单明了, 让大家知道是什么意思
//并且方法命名上也能自解释
return ...
}
要有默认值的返回
对于一个方法, 首先要有一个判定, 我的输入和输出是什么, 然后再进行具体实现. 对于输出最好有一个默认值
所以 typescript 这里做得就比较好, 如果有声明输出, 没有显示输出的话, 经常会提示错误
function returnStr() : string {
...
// 我是一个 str
return 'defaultStr'
}
写法上尽量少的创建一些中间变量
但是如果中间变量可以让代码更清晰的话, 那就创建吧. 这里想到一个例子, 比如对数组需要做一个统计返回的处理
reducer 都可以进行实现.
例如最普通的求和
const arr = [];
const sum = arr.reduce((sum, cur)=>sum+cur, 0);
例如要去遍历一个数组, 但是需要根据数组输出一个东西 (其实类似上边的求和, 复杂了一些)
const arr = [4,5,6];
const effectYourSomething = arr.reduce((effect, item, index)=>{
effect[item] = index
return effect;;
}, {})
//输出
{4: 0, 5: 1, 6: 2}
总结
一种习惯或者素养, 并且是一个不断持续的过程.