变量何时抽取以及命名位置等细节_综合

抽取变量目的是方便阅读理解

先看个代码示例，持久化文章到文件系统，分成了3步：

计算保存文件的路径
数据库存储对象转Json字符串
把json字符串保存到对应的文件中

     var articlePath = FileStoreUtil.getArticlePath(articleDo.getIdPin());var articleJson = JsonUtils.writeValueAsString(articleDo);FileStrStore.setValue(articlePath, articleJson);

为什么要抽取articlePath和articleJson变量？而不是如下代码：

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

虽然更简单，但我想大部分人阅读的时候还是会在人脑中把代码翻译为上面的样子来理解，变量是为了节省阅读者的脑运算，需要为阅读者搭建理解的梯子或台阶。

那为什么articleDo.getIdPin()不抽取个变量呢？因为本身就很易读，不需要再给台阶了。

变量命名的相对性

如何命名是相对的，方法代码块中出现的局部变量有上下文，没必要太长，但也别命名a,b,c，毕竟别人也要看，结合上下文能懂就行。JDK的var设计也是同理，局部范围结合上下文可以省略类型。

比如上面代码中命名var articleJson，很容易感知是字符串类型，如果方法上下文只操作一个实体，改为var json也是很易读的。

变量命名在所处上下文能很容易理解的前提下，尽可能短，去除无用信息。

变量定义位置

变量的声明位置应该就近，变量尽可能离使用的地方近些，减少影响的作用域。

反例,统一在函数开始声明所有变量

var a = xx;
var b = xxx;
var c = xxxx;//逻辑块1中使用变量 ab
XXXXXXXX
XXXXXX=a*bXXX
XXXXXXXXX//逻辑块2中使用变量 c
XXXXXXXX
XXXXXX=c*XXX
XXXXXXXXX

应该改为就近，当然更优秀的做法是把两个逻辑抽象为小方法,就近让不同代码块无依赖，已经为小方法的抽取做好了准备。

//逻辑块1中使用变量 ab
var a = xx;
var b = xxx;
XXXXXXXX
XXXXXX=a*bXXX
XXXXXXXXX//逻辑块2中使用变量 c
var c = xxxx;
XXXXXXXX
XXXXXX=c*XXX
XXXXXXXXX

变量其他

命名能具体就不要模糊，明明是只狗，就不要叫动物了
多维度业务数据Map嵌套结构很难看懂，最好体现每个维度的业务语义来取代Map<Map>结构。
不允许以list,map,entry,temp等命名，要思考表达的真实意思。