导言：这个题目很大，以我的水平、经验或哪个方面都是写不了的，就像 Eric S. Raymond 如果不是对 UNIX 世界的典故了如指掌的话也写不出现在的《UNIX 编程艺术》。用这个标题是因为 @vczh 对这话题有兴趣（请看靠谱的代码和DRY），这里仅是抛个砖，也算是这几年写 AutoHotkey 代码的一点心得。
怎样算好代码
如何衡量一种代码好的还是不好，我的看法是看它的价值，不过对价值的理解也因人而异。
写代码是为了解决问题，所以代码首先必须能解决问题，这是它的第一价值。它的后续价值是能否方便地重用。例如，现在要解决某个问题，我花了差不多的时间写了两段代码，它们都很好的解决了这个问题，那么能否重用就是它们价值的差异所在了。重用能提升代码的价值，重用越多价值越大化（反过来看，解决同类问题花的单位时间就少了）。
方便重用的代码一般具有下面三个特点：
- 易理解
- 可扩展
- 易维护
不论是自己以后的使用，还是分享给别人，理解都应放在第一位，只有在理解的基础上才可能去扩展和维护。
如何才方便重用
这三个特点如果从风格上描述，可概括为：
逻辑清晰
很多人有过这样的经验，小学初中写作文没有思路的时候，写的搜肠刮肚、涂涂改改，字数齐了居然自己都看不懂写了什么。
初学编程的人可能会被要求画流程图，对于写小脚本一般无需那么严谨，不过思路一定要清晰，即要解决这个问题采用这种方法时第一步应如何，第二步如何，哪里要跳转，哪里要返回，如果整个流程了然于胸要写出来就不难了。一般而言，主脚本（多脚本时）或主线程的执行流即为主要流程，其他脚本或线程为实现某个模块或某种功能，这样只看完主脚本或主线程后即能明白实现的思路了。结构良好
结构一般属于个人风格，包含很多细节，如变量命名、区块风格（大括号）、缩进、注释等。多数人认为书写风格完全是个人的事情，实际并不尽然。结构好的代码看起来赏心悦目，我们很容易理解和使用。
在官网论坛上，我们可以看到很多函数，它们一般都有个共同点：在函数顶部包含其功能说明和参数及返回值的含义，很可惜在中文论坛中大多没有，以致很多变成一次性的死代码（即分享后响应的人很少基本没人用，甚至自己以后想使用都看不懂）。
考虑协作的问题
上面所说的主要针对个人书写脚本，并没有提到协作。实际中，只要不是打算写好问题解决就扔的脚本，多少都要考虑到协作。
可能有人说，我的代码没打算让别人用，不需要协作。我个人感觉，如果从广义上看，和他人协作是一种协作，将来的自己和现在的自己协作也是一种。许多时候，我们自己写的代码，一段时间后，想要扩展发现困难重重，这虽有可能之前没有设计好或在写的过程中思路发生了变化。很多人此时就想推倒重来（重构代码），重构的精力暂且不谈，然而既然当初的想法后面发生变化，我们如何知道现在的想法以后不发生变化呢？
一而再再而三的重构就明白这种过程的痛苦了，所以更好的方法是预防，从功能上分解并模块化，例如一个脚本或函数实现一个功能。在以后整体思路确定而某功能细节的实现改变时，框架不动而只替换模块。当然，偶尔还是需要重构的，不过次数大大减少了。
小结
片面追求最精简、最优化或最高效的代码是个误区，如果注意观察我们会发现我们使用别人的代码时用的最多的是逻辑清晰、结构良好的代码，而不是那些标新立异、看起来高深莫测的代码（当然炫耀除外）。
上面谈到了，多分享也能提升代码的价值，所以看到好的代码时要不吝分享哈！
本文通篇都在说代码，但从没出现过代码，因此补充，有兴趣的朋友请看看视频网站瞬间提速，对比文中和评论中两段代码的得失之处。
