从编程的命名谈编码质量问题

望文生义正是语言文字的根本使命
服务器君一共花费了295.032 ms进行了6次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

很多人以为提高编码质量,需要很多激动人心的创新,需要明显的飞跃,这也许对,但我个人感觉项目中提高编码质量是个水磨功夫,要一步步积累,方法论大多时候帮助不大。

这次先从命名说起。

当我们看到一份设计图或一份代码时,大多数人会【望文生义】。但使人【望文生义】却正是语言文字的根本使命。因此,如果一个函数被命名为Add(),但内部实际做的是减法,那么这份设计或者这份代码,一定是很难理解的。

于是一个非常现实的问题就摆在了我们的面前:我们究竟应该如何为类,为方法等等命名?

命名而论,有两个较大的陷阱:一个是名实不符,一个是词义混淆。

名实不符的常见情形又有两类。比如:

  • 以偏概全。假设说一个方法被命名为OutputLineNumber(),但实际上这个方法会在分析源文件后,同时输出LineNumber和指定行号下的内容
  • 大而无当。假使说一个类被命名为XMLHandler,那么看得人基本不能从这个名字上获得有效信息。这主要是由于Handler这个词的含义过于宽泛。

上文所说的命名为Add()但实际做减法操作是名实不符的极端情形,达到了名实相反的地步。词义混淆则源自语言文字自身的限制。常表现为一词多义或多词一义。

语言文字可以被看成是一种表意的符号系统,这个符号系统的典型特征是其模糊性。同一个意思可以有许多种表达方法。比如说:index和number是两个不同的词,但很多时候其意义互相重叠。而假如说一个变量名为fileNumber,那么这个变量既可以代表文件的总数,也可以代表某个具体文件的编号。

上述问题会因为英语不是我们的母语而变得更为麻烦。

名实不符与词义混淆这类陷阱的一个主要触发条件是软件自身的不停衍化。在之前的文章里曾经提到过,对于概念和逻辑的认知是一个逐层递进的过程。

在这一过程中,包,类,方法等的内涵必然会发生变更。变更无疑的会使名实不符这类问题加剧。比如:一个类原本负责输出测试结果,这时候OutputTestResult这样的命名可能是合适的。可随着软件功能的增强,最终可能不知要输出结果,还要对结果进行一定分析和统计。这样原来的命名就显的有些不合适了。

在对命名这一问题的根源进行分析之后,我们来看看可能的应对方法。

命名问题事实上并不能只在命名这一环节进行解决,首先要有容易命名的对象,接下来才有容易命名的事实。比如说:是先有猫和狗这类外在特征不同的动物,接下来我们才用猫和狗这样不同的名字来称呼他们,而非相反。

如果概念之间是正交的,概念的边界也是清晰的,那么命名无疑会容易很多。好的设计是改善命名的基础。也就是说,很多时候我们感到命名困难,真正原因可能并非是命名的技能不够,而是设计还不够优化。

在努力改善设计之后,才需要面对纯粹的命名问题。从本质上来看,命名问题并不是一个编程的问题,而是一个表达的问题。命名最终对读程序的人负责。

有些表达上的基本原则对于解决命名问题会有些帮助,比如:

  • 尊重既成事实

无疑的每个人都是有创造性的,但在命名的时候发挥创造性则更可能是有害的。比如说:在XML的世界中一般使用sibling这个词来表示兄弟节点,这种时候就不需要创造性的使用brother node这样的自制词汇了。

  • 用完整词汇

 对一般人而言要求事先记忆几十个缩写词,而后来读程序是不太可能的事情。所以如果一个程序中充满_Tx和CSCP这样的特制符号的话,那这样的程序几乎一定是不容易懂的。

一个典型的反例是P.J Plauger版的C++标准模板库。也许是出于隐藏实现细节的目的,这份标准模板库的实现里面几乎完全不用完整词汇。如果想体验一下不用完整词汇的后果,那么可以读一下这里面的代码。 

  • 要具体

具体是一个方向。比如说:可以用OutputLinenumber()的时候,就不要用Output()。而可以用OutputCppLinenumber()的时候就不要用OutputLinenumber()。

  •  多人协作的时候,使用统一规范

这条规则最终会导致常说的Coding Rule。对具体如何定义Coding Rule,《代码大全》一书中给出了详细的指导,这里就不在说明了。

有一点需要补充的是,就和说话的时候记不住语法一样,设计或做编码的人往往也记不住编码规则。所以规则也不宜过多。如果必须详细,那么至少要主次分明。比如说:统一使用主宾结构还是使用动宾结构这样的选择会影响程序的大部分内容,那么就应该优先统一。

本文地址:http://www.nowamagic.net/librarys/veda/detail/1757,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/1757

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《大话设计模式》 程杰 (作者)

《大话设计模式》通篇都是以情景对话的形式,用多个小故事或编程示例来组织讲解GoF(设计模式的经典名著——Design Patterns: Elements of Reusable Object-Oriented Software,中译本名为《设计模式——可复用面向对象软件的基础》的四位作者Erich Gamma、Richard Helm、Ralph Johnson,以及JohnVlissides,这四人常被称为GangofFour,即四人组,简称GoF)总结的23个设计模式。本书共分为29章。其中,第1、3、4、5章着重讲解了面向对象的意义、好处以及几个重要的设计原则;第2章,以及第6到第28章详细讲解了23个设计模式;第29章是对设计模式的全面总结。

更多计算机宝库...