微软资深软件工程师:阅读代码真的很难
导读:原文作者Eric Lippert是一名资深软件设计工程师,从1996年起一直在微软开发部门任职,协助设计并实现VBScript、JScript、JScript .NET、Windows Script Host、Visual Studio Tools for Office和C#。
以下是文章内容:
Escalation的工程师JeremyK在他博客中问到:
你是怎么教人们快速深入挖掘不熟悉的代码(不是自己所写的)?我学习如何编程的方法很传统——自己动手编码。但我现在很纠结:到底是集中精神阅读源码,还是自己编写。对我而言,似乎唯一有效的方法就是自己写过。
Eric Lippert:不是和Jeremy开玩笑,写代码的确没有读代码难。
首先,我同意你的看法,几乎很少有人能读代码但不会写代码。这不像自然书面语或口语,理解他人的意思并不需要去理解他们为什么要那样说。比如,如果我说:“写代码有两种方式:一种严格且详细,另一种模糊且草率。前者生成简洁分层的婚礼蛋糕,后者却是意大利面条。”上面这句话产生一个平衡且幽默的效果,但即使听众和读者不理解我使用“零照应”和“并列句”这样的文字技巧,也会理解我要说的意思。但是说到代码,既要从代码本身中理解代码作者的意图,又要理解代码产生的预计效果,这两者都极为重要。
因此,我又回到那个问题了,有些人需要快速切入代码,但不需要动手写代码,那我们如何编写适合这些人的代码?
下面是我在编写代码时,尽力去做的事,目的就是使其他人能轻松阅读:
使代码遵从工具。Object Browsers和Intellisense虽然很好,但我告诉你,我是守旧派。如果找不到我想要的,我会不高兴。什么使得代码成为可查询的呢?
像“i”这样的变量名不好。如果没有明确的错误提示,你就无法轻易查找代码。
避免使用是其他名字前缀的名字。比如,在代码中有个“perfExecuteManifest”,如果再有一个“perfExecuteManifestInitialize”,这就会让我抓狂,因为每次在源码中查询前者时,我不得不费力地过滤掉后者所有的实例。
“临时传递数据”(tramp data)应使用相同的名字。所谓“临时传递数据”(tramp data),就是指那些传递给方法A的变量,还要传给方法B的变量。这两类变量实际上是相同的,所以如果它们有着相同的名字,则更好。
别用宏来重命名东西。如果有个方法叫get_MousePosition,那别这样GETTER(MousePosition)来声明该方法。因为我会找不到实际的方法名。
Shadowing会引起很多问题,请不要用它。
坚持使用一种命名模式。如果你打算用匈牙利命名法,那就坚持并广泛使用,否则将适得其反。使用匈牙利命名法来记录数据,而不是存储类型;记录普遍事实,而不是临时条件。
使用断言来记录先决条件(preconditions)和后置条件(postconditions)。
别缩写英文单词。确切来说,别缩写成稀奇古怪的形式。在脚本引擎中,有个变量名叫“NME”,这让我非常抓狂!它应当叫“VariableName”。
C语言标准运行时库的设计不是很优秀。别去效仿它。
别写“聪明”的代码;当代码出现问题,维护代码的程序员没时间去理解你的聪慧。
理解编程语言特性的设计初衷,使用这些特性去做它们适合完成的工作,而不是它们能做到的工作。例如:别把异常当做一般的流控制机制来使用(即便你能做到),而应该用它们来报告错误。别强制把接口指针转换成类指针,即便你知道这样没问题。
按功能单元划分源码树,而不是按组织结构。比如:我目前所在团队中,有2个根子目录的名字是 “Frameworks”和“Integration”,这是两个团队的名字。不巧的是,Frameworks团队名下有一个叫“Adaptor”的子目录,而“Adaptor”却是Integration的子目录,这就非常令人迷惑。同理,(如果)有着相同子目录的不同的子树,有些是客户端的组件,有些是服务端的组件;有些是管理组件,有些是非管理组件;有些是处理型组件,有些是非处理型组件;有些是零售组件,有些内部测试工具。这就会乱七八糟的。
当然,我实际上根本没有回答Jeremy的问题——如何调试不是我写的代码?
这取决于我的目的。如果我只是因为一个Bug,而深挖一段具体的代码,我会在调试器中逐步跟踪所有代码,写下我“走过”的调用分支,记录下哪些方法是特定数据结构的“生产者”,哪些方法是“消费者”;我也会仔细盯着输出窗口,查看出现的有用信息;还要打开异常捕捉器,因为异常通常是问题所在。设置断点;我会记录所有和我上面建议相反的地方,因为这些东西很可能误导了我。
如果我想在理解一段代码后修改它,我通常是从代码头部开始,或者先查找公共方法。我要知道类是如何实现的,它是如何扩展的,它的作用,它是如何嵌入整个代码中的?我会尽力理解这些东西后,才去了解这些特定部分(代码)是如何实现的。这耗时虽更长些,但如果你准备改动复杂代码,你应当那样做。
译文链接:http://www.jobbole.com/entry.php/438
原文链接:http://blogs.msdn.com/b/ericlippert/archive/2004/06/14/reading-code-is-hard.aspx
分享到:
相关推荐
通过阅读《软件工程师典藏:MFC程序开发参考大全》并实践其中的代码,开发者不仅能掌握MFC的基本用法,还能提升解决实际问题的能力,从而在Windows应用程序开发领域更加得心应手。书中提供的光盘资料和代码示例无疑...
【标题】:“微软内部所有工程师必读之书”这一标题暗示了这是一系列书籍,专门针对微软公司的工程师们,旨在提升他们的专业技能和对微软技术生态的理解。这些书籍可能涵盖了微软的各种开发工具、操作系统、软件工程...
Wright是微软的资深工程师,书中可能涵盖了代码质量、可维护性、性能优化等方面的知识,这些都是微软工程师必须掌握的核心技能。 2. **打开方式.htm**:这个文件可能是关于如何有效阅读和利用微软内部文档的指南,...
**微软一站式代码示例编程规范** 编码规范是软件开发中不可或缺的一部分,它为开发者提供了一套统一的编写代码的标准和指南,确保了代码的可读性、可维护性和团队协作的效率。微软作为全球领先的软件公司,其编码...
在微软的技术支持工程师面试过程中,技术测试部分通常涉及广泛的知识领域,包括但不限于操作系统原理、网络技术、编程基础、软件调试和问题解决能力等。这份技术测试文档(OLC.Technical Test.doc)可能会涵盖以下几...
微软作为全球知名的科技巨头,其软件工程师面试流程严谨且具有挑战性。对于有意加入微软的软件工程师来说,了解并准备这个过程至关重要。以下是从提供的文件内容中提炼出的关键知识点: 1. **简历个性化修改**:...
【标题】: 微软技术支持工程师笔试题 在IT领域,微软是一家全球知名的技术巨头,其技术支持工程师的角色至关重要。这份笔试题旨在评估应聘者在语言理解和技术应用方面的能力,为微软提供高素质的技术支持团队。语言...
标题中的“微软工程师推荐的清理工具2.0”指的是一个由微软工程师认可并推荐的系统清理软件的新版本。这样的工具通常旨在帮助用户整理和优化他们的电脑,清除无用的文件,提高系统性能,并确保数据安全。 描述中...
葛佳亮和蒋里京作为作者和翻译者,与Dan Ruder(微软资深升级工程师)及多位项目经理共同参与了编程规范的制定。Dan Ruder凭借其丰富的编程经验,对文档进行了细致的审阅和修改,确保了规范的专业性和实用性。此外,...
【微软国际认证题库】是针对想要获得微软认证的软件工程师们的重要学习资源。这个题库包含全英文的试题,确保了与国际标准的一致性,对于那些希望在全球范围内提升自己技术能力的专业人士来说,这是一个宝贵的练习...
【微软研发探秘系列课程(1):卓越软件开发工程师】是针对软件开发人员的一门专业课程,旨在提升开发者的技能和工作效率,帮助他们成为卓越的软件开发工程师。本课程内容丰富,包括PPT讲解、视频教程以及相关文档和...
微软一站式示例代码库 (Microsoft All-In-One Code Framework) 由微软社区技术支持团队为您倾力呈现。我们编写相应的代码示例,并以很短的周期发布更新...微软工程师会第一时间为您评定请求是否典型,并提供示例代码。
微软软件外包项目的承包商团队包括公司高层决策者、项目经理、开发领队、开发工程师、测试领队、测试工程师等几个方面。 案例:第一阶段 微软软件外包项目的第一阶段包括项目经理为承包商的团队成员申请暂时的用户...