code review常见问题

catch代码块为空

正确做法是提示错误信息、上报异常信息、其他业务逻辑。

如果不需要处理的话，就不应该使用catch。

函数入参个数太多

使用者需要关心参数的个数和顺序，有很大的心智负担。

正确做法是合并参数为对象，然后进行解构。

魔法数字/字符串（硬编码）

硬编码会带来若干问题，维护人员不太清楚其含义，另外会有可能的耦合。

定义常量来取代魔法数字/字符串，同时使用语义化的变量名。

不合理的注释

const id = 1 // 定义id为1 => 定义要查找的文章id

简化逻辑分支

function counter(state, action) {
  switch (action.type) {
    case "increment":
      return state + 1
    case "decrement":
      return state - 1
    default:
      return state
  }
}

应该使用策略表进行优化

function counter(state, action) {
	const ins = {
		increment: 1,
		decrement: -1,
	}
	return state + (ins[action.type] || 0)
}

条件判断过于复杂

function checkGameStatus(){
	if(条件1 || 条件2 || 条件3){
		quitGame()
	}
}

应该单独抽离一个判断函数，保持主要流程的简洁

function isGameOver(){
	return 条件1 || 条件2 || 条件3
}
 
function checkGameStatus(){
	if(isGameOver()){
		quitGame()
	}
}

卫语句（提前返回）

有时候业务处理和错误处理代码揉杂在一起了，代码很难看懂。

正确的做法应该是先处理所有的错误场景，然后提前返回，剩下的再处理正常的业务流程。