谨慎行事,请编写面向阅读的代码
编写易于阅读的代码
你可能想着,我代码不是给其他人看的,所以没必要写的那么容易理解。
但是有可能的是,不管怎样,还是会有人在机缘巧合之下研究你的代码,并努力搞明白代码的意图。
而这个人,非常有可能就是编写代码 1 年后之后的你。
我曾经在一篇文章中写道,在设计函数原型的时候,尽量不要使用布尔类型作为函数的参数。有人就说了,”这个应该问题不大吧,你看现在的集成开发环境的 Intellisense 都有自动提示功能帮助编写代码了。”
是的,当然,他说的没错。集成开发环境确实可以帮助开发者快速编写代码,但是代码可能只会编写一次,但是你可能会多次阅读它。
有人又说了,”如果我阅读代码时没能理解函数的意图,我大可以将鼠标悬停在函数上,函数的原型及意图我就基本明白了。”
这确实是一个方法,但却不是一个完美的解决方案。
第一,你在阅读代码时必须握着鼠标来操作。
其二,这意味着你不能更加高效地浏览代码。例如,因为你将点击一个 CreateEvent,然后必须等待一段时间才能显示工具提示,然后读取和解析工具提示,并将参数与屏幕上的参数相匹配。这会打乱你的节奏。
想象一下,如果您必须阅读经过 ROT-13 过滤器(一种加密算法)的代码。当然,如果您将鼠标悬停在光标上,IDE 可能会通过解码光标下的文本来帮助您,但即使是即时的,理解代码的速度也不够快。
最后,另一位评论者也指出,如果你在集成开发环境之外的任何地方阅读代码,阅读设计糟糕的代码可能会是一场噩梦。
代码可能在杂志中,在打印输出中,在错误报告中,在高架投影仪上,在网页上,在Usenet消息中,或在电子邮件中。
在这种场景下,就没有 Intellisense 可以使用了。
那就 BBQ 了。
总结
这里有一个先苦后甜的道理:在设计接口或者函数的时候,多琢磨琢磨,如何让接口的使用者更加容易理解,容易调用。
这不光方便了接口的使用者,也会对编写代码的你产生深远的正向益处。
可别胡乱一通操作,并想着 “又不是不能用”。
最后
Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一,里面有很多关于Windows的小知识,对于广大Windows平台开发者来说,确实十分有帮助。
本文来自:《Code is read much more often than it is written, so plan accordingly》
最近我写了个东西
正如你们所知道的,拓扑梅尔智慧办公平台(Topomel Box)是一款绿色软件,主要面向经常使用电脑的朋友。它提供了各种提升办公效率的小功能,同时操作上尽可能地简单方便。
我想:你值得拥有。
- 下一篇: 我们需要先弄明白头文件的默认版本
- 上一篇: 为什么不能在一个禁用的窗口上显示工具提示?
相关推荐
- 析构函数在什么情况下应该声明为虚函数
- Posted on 02月21日
- 使用C++ Build Insights对模板代码进行性能分析
- Posted on 05月31日
- Visual Studio 新特性:对 include 指令进行智能诊断
- Posted on 01月10日
- strncpy很危险,但是为什么VS2005还支持它?
- Posted on 11月13日
评论已关闭。