大家的英语都是very good, 但这里有个问题, 就是这段代码里的命名是否真正的体现了代码的核心含义就很重要了。举个简单栗子, 在一个业务场景中有这样一个问题 ‘If your customer just considers “order” an “order” that has been approved, don’t call “order” to a non approved one in your code, call it “nonApprovedOrder”’ 翻译一下就是你的客户只会‘订购’那些被批准了的‘订单’，那么你在一段代码里出现了order这个变量，此时就会很模糊了，模糊的关键就在于order到底是被批准了，还是未批准呢？可能你会说order对象有个属性来表示是否批准了。当然这是可以的，但若是我直接使用nonApprovedOrder是否会更清晰呢！这里只是举个简单例子，也并不代表一定得这样，其实order下的属性判断我觉得也是可以的，这里只是为了说明一个问题，能让人一目了然的命名才是更合适的。
把业务领域的术语对应到你所熟知的命名上去
栗子： If your customer just considers “order” an “order” that has been approved, don’t call “order” to a non approved one in your code, call it “nonApprovedOrder” 同上
软件是如此的复杂之命名(我们只谈语义问题不谈逻辑问题)
让机器懂的代码很简单，让人懂的代码就很难了。 其实代码也是在写作（虽然也大不相同），我现在发现能将自然科学和人文科学完美结合的就是计算机科学了。因为一段正确的代码需要正确的算法逻辑甚至是数学证明，事实上计算机科学发展的基础就是数。可是代码追求的不仅仅是正确，还得是可维护的，就是说是人可以读懂的。那么这时候就要看你的英语功底了，其实也不尽然，但是良好英语功底得是有的，只要你想写出大家可以看懂的代码（此处省略一万字别较真...）。 关于代码写作，大部分不是在写完整的句子，反而大部分是在写短语，是在给事物进行命名处理。而是否写的好，这里有两方面的问题：
看了上面两个问题就会发现，你写了一个正确代码，但却不一定写得出可读的代码。接下给大家看一些关于命名原则
好的栗子：daysDateRange, flightNumber, carColor 坏的栗子：days,dRange,temp,data, aux
坏的栗子：howLonDoesItTakeToOpenTheDoor, howBigIsTheMaterial... 好的栗子：timeToOpenTheDoor, MaterialSize
用缩写没问题，关键得有注释，或者是大家都知道的通用缩写
在需要的时候适当使用匈牙利标记法。 举个栗子： 你需要根据苹果的颜色来区分是否成熟 你可这么来命名 red_apples, yellow_apples ...
保持一致性 如果采用驼峰式就都使用驼峰式
把业务领域的术语对应到你所熟知的命名上去 栗子： If your customer just considers “order” an “order” that has been approved, don’t call “order” to a non approved one in your code, call it “nonApprovedOrder” 同上
黄金条例： 花一些时间再命名上（我觉得这条是最靠谱的，我也要贯彻执行） 当你近乎不加思索的使用一个变量命名的时候，你基本上就已经选择了一个不好的命名。 反之，你总是在向着好的命名前进
那怎么判断我们的命名是合适呢？当我们的命名ok时代码应当呈现以下几个特征
当然一次性就改好了是在太困难了，那我们以前的旧代码怎么办？
一句话对我们的代码持续性重构，以及持续性的测试。因此我们需要大量的测试用例，是的，测试用例。
最后一个真的是太重要了。