编码风格，是的，最近很想写点什么，特别想写的一篇就是关于编码风格。
我最近的Skype签名是这样的：
Programs should be written for people to read, and only incidentally for machines to execute.
这是SICP里面的一句话。当时读到的时候立刻就被感染了，说的真的是太好了。一直以来，我都觉得写程序这件事儿是一种创造，而创造这项活动，必须至少有一些艺术在里面，才能称得上优秀的创造。对于程序来说，实现它的那些code，可以很大程度表现出这个程序的优秀与否。虽然我一直很赞同结果导向，虽然我也觉得软件的最终价值是它的商业价值，高质量的服务了多少客户。但是，code质量是商业价值实现的前置必要条件。我绝B不相信，一个code一团糟的项目能够获得成功，即便能在某种程度上获得一定成功，但如果code有更好的质量，绝B可以获得更大的成功。
虽然说凡事要摆事实讲道理。但我相信对于在一线写code有段时日的程序员来讲。即便不拿出事实，都会有自己非常准的直觉知道code的新鲜/腐烂度，知道code的质量，知道哪里有bad smell，哪里如果哪儿再不打理，将来会有很大的潜在风险。所以，我觉得给予必要的时间，让程序员可以精心的维护自己的code是非常重要的一件事儿。
最近，正好有这么个机会，项目要从Rails1.x升级到Rails3.x，花费了不少人力物力时间成本，而我也觉得这是一个很好的机会多做一些还(技术)债的工作，于是就想了一些事项。但最后决定还是从统一代码格式入手，虽然目前这个事情离彻底完成还要很久，但已经有很多值得分享和说道的地方了。
- Code Style真的是万事之首，基本的基本。我本想着着手重构一些地方，但重构的前提是要理解原有的code，而当代码的样式乱到一个相当的高度的时候，，真的会让人抓狂，根本就读不懂，比如说一行就二百左右的字符，充斥着&&、||和小括号、括号嵌套括号的各种条件判断。你不想把样式调整到一个比较让人接受的程度，是根本没办法轻易理解，进而改进的。
- 发现潜在的bug。嗯，至少对于Ruby来讲，因为是解释性的语言，少了编译的步骤，代码中更容易有一些潜在的bug。比方说不存在的变量，重复定义的方法，或者永远为true或者false的判断之类等等。而在统一code style的过程中，随着提高了代码的可读性。这些潜在的bug也会很容易的浮出水面。
- 发现bad smell，对于bad smell的定义，我认为就是那些逻辑正确，但是实现方式很ugly的code。而当你整理一段糟糕的code，然后经过一番思考，尝试，搏斗。发现怎么调整，这段代码都达不到很高的可读性，总是看起来特别扭。那么，就可以立刻将这段code标记下来，或者立刻着手重构了。毕竟，在性能没有那么高要求的B2B的web项目中，着实不会有太多必须存在为了性能妥协的各种脏code。所以，一般情况，只要发现了这些bad smell，其实都能够比较轻松的进行不同程度的重构，来改善局部的设计和代码质量的。
上面说到的都是一些很实在的看得见的现实意义。而其实我觉得在精神层面上的意义也许更大。打个比方吧。找一篇宋词解析，先把某篇词后面的全文注解这个冗长乏味的白话文看一遍，然后再读一下词本身。你立刻就能感觉出后者的精练，美感和为何流传于世。code也是一样的，但你打开一个source file，发现style调整的非常精良，易读，这种感觉和看到各种千奇百怪的写法，随意命名的变量方法名拼装的源码，是完全不同的。
因为这事儿基本算计划外的，只好更多的是在下班后去做。所以按照现在的进度和整个项目的代码行来说。可能还要2、3个月的时间，才能将整个项目的source file过一遍。但我还是觉得这是一项非常值得的事情。不为别的，就是将来需要维护它的新人来后看code不会产生我当初那种骂街悲愤的感觉，就是值得的。
美是存在于每个地方，不只是和搞艺术的有关，程序中也可以时刻有着美的体现。