代码简洁之道(读书笔记)
前序（仅个人观点)
- 好看才是第一生产力，不好看的代码，根本没法谈性能，就像一个女孩子，灵魂再有趣，没人理你
- 习惯写好看的代码，而不好先写出来不好看的代码，然后说后面再优化，你根本就没有时间，其他人也不敢动你的代码,稍后等于永不！
- 代码好看，意味着逻辑清淅，易读，易coedreview,易找bug,易优化
- 通常自己写的代码，别人比自己读的机会更多，写好看了自己读起来也开心
- 编码是一种社会活动
命名
- 使用能读出来的单词或短语拼接，避免codeReview的时候自己像傻吊一样念字母
- 除了stream箭头函数变量和for循环变量i,其他地方不应该出现单字母变量
- 避免使用var1,var2，account1,acccount2这样的命名，这看起来机器反编译的，不像工程师写的
- 做有意义的区分，类名Account,AccountInfo,AccountData，虽名称一样，但意思没有区别
- 类名/对象名用 名词短语(名词+作用+领域，AccountParserService），方法名用动词短语(parseJson,fromJson)
- 好像类名这个规则实施起来有点难,经常看到动词开头的类名
- 取名字最难的地方在于需要良好的描述技术和共有文化背景。(书上原话)
函数
- 短，尽量短（原书观念，待商榷，在不利用的情况下，三行代码提成一个函数是否有意义呢）
- on thing,not more,not more,not more
- 只做一件事，且做好这一件事
- BUT：在实际开发的时候，我们光明正大的把函数声明为可以做两件事，甚至更多事，比如：
- 以and连接的函数名
- 其他一个参数为Boolean的函数
- 其中一个参数为null值的函数
- 具体实现待探讨
- 每个函数一个抽象层级，即函数中的语句在同一个抽象层级上
- 业务是最高层
- 业务下有一层或两层
- 外部client调用/util类属于一层
- java 基础类相关的在最底层
- 向下规则，即 每个函数后面跟着下一层级的函数
- 遵循向下规则像是一系列TO起头的段落，比如要创建一个用户，先校验用户名，然后校验密码，然后对密码进行加密，然后保存到数据库，最后返回userId，我们就形成了一串子函数抽象,比如(checkUserName(),checkPassword(),saveUser())
- 个人理解是面得TODO编程，正常情况下先写todo逻辑，可以在写todo的时候更进一步的把下一步抽象函数名及参数写好
- switch,书中建议仅用于创建多态对象(sounds good)，而我根本不用，java的switch根本不好用，不支持条件,并且语义上也没有if else清淅
- 函数参数,书中建议 0 优于1，1优于2，避免 3+
- BUT：0过于苛刻，比如一个web请求，至少得有request吧，或是每个请求封一个对象？
- 1个参数没问题，两个的话如果类型一样的，容易传错
- 2个以上建议封装成对象
- 参数列表，没有异义的情况下没有啥子问题，但像log.error(String format,Object …args),这样的就很难判断，最后传一个e是不是可以正常处理，虽然细看Slf4j是可以按我们的要求处理的，但如果你之前用的是log4j就会有点蒙
- 无副做用
- 不对传入参数做手脚，进来是啥出去还是啥
- 要做的事和函数名描述一致
- 无副做用也可以保证其他人放心的调用此函数