对于一个开发人员来说，保持代码的整洁是十分重要的。有时候，即使是我们自己写的代码，过了一段时间，对其修改时都要花费很长时间，唯恐一不小心就犯了错，更别提修改别人的代码了。
于是我们立下目标，下次开发我一定要好好整理我的代码！然而当实际开发的时候，却发现自己对如何编写“整洁”的代码，好像并不是很清楚。
《重构》里有这么一段话：
“任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。”
写出令人容易理解的代码不是一朝一夕就能达到的，但是我们可以通过对细节的注意，在编写代码时秉持适当的原则，不断的磨练自己写出好代码的能力。
粗浅读了代码整洁之道之后，对如何写出整洁的代码有一些的思考。
1.开发时保持代码整洁
命名、注释、函数和格式
命名要名副其实。 起名时：类名和对象名应该是名词或名词短语，方法名应该是动词或动词短语，属性访问修改等应该根据对应值命名，并在前加入get,set,is等前缀。起名字时要避免误导，比如书中提到的别用accountList来指一组账号，除非它真的是List，否则可能会引起错误的判断。长而具有描述性的名称比短而费解的名称好。命名能够足够语义化，能够帮助我们在阅读代码时快速理解变量和函数的含义。
唯一好的注释是你想办法不去写的注释读过书之后我对注释有了新的认识。在原来开发的时候，我认为注释详细一些比较好，这样我们能够更清楚快速的了解代码的用途。但是读过书之后，我的思想发生了转变，书中的观念是，我们应该把心思花在写清楚代码上，直接保证无需编写注释。真正好的注释是你想办法不去写的注释。应该尽量用代码去阐述我们的目的。
函数应该做一件事。做好这件事。只做这一件事。 在这段时间的开发中，在我提交代码的批注中我好像也看到了这句话，函数不应该过长，应该足够短小精悍，让人尽快的明白这个函数到底做了一件什么事。函数的参数应该尽可能少，三个或三个以上的参数，就说明部分参数应该封装为类了。同时，参数过多也不易测试。
代码格式很重要。 代码的格式关乎沟通，而沟通是专业开发者的头等大事。现在编辑器格式化的插件已经很多了，我们要保持代码的格式整齐也不是难事，但是在配置插件的时候也确实要花一些心思。
2.代码的质量保证
错误处理和单元测试
错误处理是编程是必须要做的事。 错误处理很重要，但如果他它搞乱了代码逻辑，就是错误的做法。将常规流程与错误处理分离开，能够保持代码的简洁和简朴，提高代码的可维护性。
单元测试使代码可扩展，可维护，可复用。 我之前对于测试的了解很少，随着对测试的了解越多，越发现测试的必要性和重要性。以测试为驱动的开发模式最大的好处就是确保一个程序模块的行为符合我们设计的测试用例。在将来修改的时候，可以极大程度地保证该模块行为仍然是正确的。有了测试就不用担心修改代码，没有测试，在修改的时候我们就不必担心会影响之前的功能。测试也需要保持整洁，否则到后期就会无法维护测。测试要采用构造-操作-检验模式，每个测试均要可以清晰的拆分为三个环节，第一个环节构造测试数据，第二个环节操作测试数据，第三个环节检验操作是否得到期望的结果。整洁的测试应该遵循F.I.R.S.T原则（快速、独立、可重复、自足验证、及时）。
3.小结
整洁的代码并非遵循一套规则写就，学习一系列启发并不足以让你成为软件匠人。专业性和技艺来自于驱动规程的价值观。
小到命名和注释，大到类和系统，书中从各个方面讲述了如何尽可能的保持代码的整洁优雅，达到书中所涉及到的方方面面不是一朝一夕可能完成的，而是在对自身有要求的前提下不断磨练自己的代码才有可能做到的。在序中，作者将“阅读本书并应用它”称为一种挑战 ，体现的是一种负责任的专业精神，这种专业性隶属于关注一个产品生命周期的专业领域。成为一个负责任的专业人士，应该是各行各业的从业人员都对自己拥有的期待和要求。
要加油呀。
