PrettyCode

一直在思考代码的写法，怎么样才是最好的，中间想法经过几轮变化，没有经过多次沉淀之前，就算有人告诉你真相，你依然不会相信；最终沉淀下来的却比想象中还要简单；不敢保证写下的一定正确，但只要写下的，都是自己此刻认可的，都是自己写代码的原则。 为了说明白，有些会给出一些示例代码，代码示例主要来自https://github.com/qiuriyuchen/fly。

 怎么写代码

经常Review别人代码的时候，当发现代码逻辑混乱，我会问个这个问题，你先忘记代码，用业务语言说下逻辑吧，然后说的挺好，逻辑分成ABC三步，A是怎么做的(a1,a2,a3)，B是怎么做的(b1,b2,b3)，C是怎么做的(c1,c2,c3)；然后我会问为什么程序不是这么划分的呢？

1. 层次结构和说的不一样，说好的ABC呢（比如a1,a2在一起，a3和b1在一起）
2. 方法抽取也和说的不一样（比如a1 a2不见了,抽取了个方法ax包含a1和50%的a2，抽取了ay包含了50%的a2和a3）
3. 对等关系也不一样，（ABC三步不见了，出现了XYZ...AB步骤，说好的ABC对等呢）

我想，你已经知道我在说什么了，写代码就是把业务逻辑先用语言能说清楚，然后用代码表达出来的过程；如果你有这个问题，如果一个人没办法通过语言梳理说清楚业务逻辑呢，那还怎么指望能写出正确的代码呢？更别说漂亮的代码，还是辞退或换岗吧。

变量命名

• 命名能具体就不要模糊，明明是只狗，就不要叫动物了
• 业务Map结构命名最好体现维度 业务实体类型_key维度类型，方便代码阅读。
• 不允许以list,map,entry,temp等命名，要思考表达的真实意思。
• 局部变量有上下文，没必要太长，但也别a,b,c，毕竟别人也要看，结合上下文能懂就行。JDK的var设计也是同理，局部范围类型可以省略
• 局部变量声明就近原则，别距离使用老远。
• 如果有些表达式可读性差，最好抽取个变量，节省阅读者的脑部运算

变量命名

• 命名能具体就不要模糊，明明是只狗，就不要叫动物了
• 业务Map结构命名最好体现维度 业务实体类型_key维度类型，方便代码阅读。
• 不允许以list,map,entry,temp等命名，要思考表达的真实意思。
• 局部变量有上下文，没必要太长，但也别a,b,c，毕竟别人也要看，结合上下文能懂就行。JDK的var设计也是同理，局部范围类型可以省略
• 局部变量声明就近原则，别距离使用老远。
• 如果有些表达式可读性差，最好抽取个变量，节省阅读者的脑部运算

  

    var articlePath = FileKeyUtil.getArticleKey(articleDo.getIdPin());
    var articleJson = JsonUtils.writeValueAsString(articleDo);
    FileStrStore.setValue(articlePath, articleJson);

此处的articlePath和articleJsonbian变量，就是为了节省阅读者的脑运算，你如果写成如下代码，虽然更简单，但我想大部分人阅读的时候还是会在人脑中把代码翻译为上面的样子，然后理解

FileStrStore.setValue(FileKeyUtil.getArticleKey(articleDo.getIdPin()), JsonUtils.writeValueAsString(articleDo));