名可名

谈谈命名，大家可以吐槽下不好的命名例子，也可以讲下自己学到的命名原则及模式。

代码中命名的一大槽点就是重复的前缀太多，这主要是由于缺乏对函数的封装，OO 不仅是聚合数据，更主要是封装应用在该数据上的函数。

所以当碰到函数没地方放，成为全局函数时，需要好好考虑下是不是领域边界没有划分清楚，对象关系是否分隔妥当。

怕重名，是不是封装不够？

有重名，说明可提取抽象，这时应该考虑下抽象个接口。

对于函数内的临时变量，更没必要加个类型前缀，如用 ast 表示一个结构体。

C 语言这个恶习是担心变量定义和使用离太远了，回去查找麻烦，且不说 IDE 把鼠标放到变量上就能显示变量的定义，这个担心的一个条件是函数太大了，正解应该是拆分函数。

bool 命名要注意避免模糊，要能清晰的表明真或假。具体是以真为主，还是以假为主，看你业务逻辑的默认逻辑应该是主，还是假。

说白了就是要让主流程代码是 if (enabled)，避免出现 if (!enabled)，后者应该命名 if (disabled)。

提前 return 的不是主流程，就要加个！，不加反而麻烦。

遇到判断逻辑，首先考虑好默认/或大概率是真还是假，然后把它作为主流程，剩下的作为异常流程。

简单说，命名以主流程为主，异常流程就拿主流程的命名，然后前面加个！

由于判断逻辑太常见了，可参考 rust 语言级别的最佳实践：

空值抽象 Option 类型，有 Some<T>, None 两个值；

错误值抽象 Result 类型，有 Ok<T>, Err<E> 两个值。

精髓在于：是判断就必须显式写代码处理，未处理的判断分支、未处理的返回值会编译不过。也就是只有 if，没有 else 的代码是坏味道，这块也是 bug 温床。

关于 bool 逻辑命名，非功能需求/null、err 就用 Option，Result 包起来，功能需求就起个业务领域的名字，来表达主流程。

Option 好多语言也有了，Result 其实就是错误处理规范，大一点软件都有套类似的明确的错误处理规范。