编写易于阅读的代码
你可能想着，我代码不是给其他人看的，所以没必要写的那么容易理解。
但是有可能的是，不管怎样，还是会有人在机缘巧合之下研究你的代码，并努力搞明白代码的意图。
而这个人，非常有可能就是编写代码 1 年后之后的你。
我曾经在一篇文章中写道，在设计函数原型的时候，尽量不要使用布尔类型作为函数的参数。有人就说了，”这个应该问题不大吧，你看现在的集成开发环境的 Intellisense 都有自动提示功能帮助编写代码了。”
是的，当然，他说的没错。集成开发环境确实可以帮助开发者快速编写代码，但是代码可能只会编写一次，但是你可能会多次阅读它。
有人又说了，”如果我阅读代码时没能理解函数的意图，我大可以将鼠标悬停在函数上，函数的原型及意图我就基本明白了。”
这确实是一个方法，但却不是一个完美的解决方案。
第一，你在阅读代码时必须握着鼠标来操作。
其二，这意味着你不能更加高效地浏览代码。例如，因为你将点击一个 CreateEvent，然后必须等待一段时间才能显示工具提示，然后读取和解析工具提示，并将参数与屏幕上的参数相匹配。这会打乱你的节奏。
想象一下，如果您必须阅读经过 ROT-13 过滤器（一种加密算法）的代码。当然，如果您将鼠标悬停在光标上，IDE 可能会通过解码光标下的文本来帮助您，但即使是即时的，理解代码的速度也不够快。
最后，另一位评论者也指出，如果你在集成开发环境之外的任何地方阅读代码，阅读设计糟糕的代码可能会是一场噩梦。
代码可能在杂志中，在打印输出中，在错误报告中，在高架投影仪上，在网页上，在Usenet消息中，或在电子邮件中。
在这种场景下，就没有 Intellisense 可以使用了。
那就芭比Q了。
总结
这里有一个先苦后甜的道理：在设计接口或者函数的时候，多琢磨琢磨，如何让接口的使用者更加容易理解，容易调用。
这不光方便了接口的使用者，也会对编写代码的你产生深远的正向益处。
可别胡乱一通操作，并想着 “又不是不能用”。
最后
Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。
本文来自：《Code is read much more often than it is written, so plan accordingly》
