关于代码风格的规范

在《百年孤独》这本书的开篇里，加西亚 马尔克斯回忆了一个时代，那时『这个世界刚刚出现，以至于很多东西缺乏命名』，这时就有必要亲自用手指明这些事物』。
我们赋予这些东西名字的时往往是很随意的。
这就好比说为什么猫不被叫做狗，而狗为什么不被叫做猫一样，没有什么理由可言。
——《编码》

代码是用来读的，只是刚好可以被计算机执行而已。
——《SICP》

主要记录如何把代码写好的一些方法，我想到哪写到哪，不定期修改。
相关的参考书籍有很多，比如《代码大全》，《重构》（重构最新版本是用 JS，老版为 JAVA）。
一切以可读性为前提并尽量保持简洁使代码具有自说明能力。

变量

变量的命名应该和具体的实体有关，设想如何让一个不了解这个代码功能的程序员读一遍就知道它是做什么的。
关于变量名称的详细程度，需要根据变量生命周期来决定，比如你弄了个全局变量，字符多一些不存在什么问题（为了避免和局部变量冲突）。
但如果只是一个只存活在一小段代码里的计数器变量，用 i,j,k 之类的单字母变量也是可以的。
少用 is_xxx 之类的开头
比如是否干净的命名应该为 cleaned，而不是 is_cleaned，因为 cleaned 本身已经足够表示 已经 的意思。
另外。。。千万不要写出 下划线 + 驼峰 的格式。
变量应该在接近使用它的地方之前声明，有些人很喜欢在每个函数的开头把所有要用的变量声明一遍，或者在把所有功能写完之后将变量全部挪上去，其实这样是错误的，非常不利于代码阅读。
能用局部变量就不要去使用成员变量，如果流程很长，使用成员变量来在一个业务逻辑中的各种方法之间进行穿插，当需要调试的时候就不得不去监视它在每一个流程可能会发生的值的改变，这很难追踪，测试。
良好的程序应该尽量是[输入->输出]的集合，而不是让函数带副作用去更改某些外部环境的值，这很难调试！

逻辑

学好命题与逻辑（其中的真值表与德摩根定律会对你处理业务逻辑有很大帮助)，在修改一些新手写的 legacy code 的时候甚至都不需要去理会它本身的业务逻辑就可以直接进行逻辑简化，之后再来了解业务逻辑。

函数

小驼峰格式 messageFromServer，控制好每个函数中内容的行数，如果它太长了，就要进行拆分。
另外，关于是否应该使用 setXXX getXXX，个人认为这两种方式主要用于对象属性操作，而不是针对其他功能，待定。

注释

实际上，好的程序员会写下两种目的的注释
一种给可能需要修改该程序的读者
一种给需要使用该程序但不去读它的读者