100、20不是代码行数,是函数的圈复杂度(《代码大全》里有讲什么是圈复杂度),我们用SourceMonitor度量出来的,好像VC2008也
有这个功能。
On Sep 22, 9:25 am, Shuo Chen <giantc...@gmail.com> wrote:
> 100行的函数不算长吧?20行更算是短函数了。
> 特意把函数写短不是难事,无非是把参数传来传去,或者把状态保存在成员变量(甚至全局变量)里。这样每个函数都能写到5行以下,但是这就是我们的目的
> 吗?
> 短的函数,就其个体而言,确实比较容易理解。不过就整体程序而言,就不一定比长函数更容易理解了。因为读起来跳来跳去的,还得记住调用栈和上下文,不见
> 得比读长函数省劲。
> 我觉得200行以下的函数都可以接受,我们项目里最长的函数大概150行。
> missdeer wrote:
> > 最近一直在学习Martin Fowler的《重构》,并且对照我参与的一个已经投入至少15人年,历时3年,约20万行,目前仍然在继续开发维护
> > 的项目,让我觉得触目惊心,其中的代码,到处充斥着Martin Fowler所谓的坏味道,而又困惑重重,不知道别的项目代码质量是如何的。
> > 下面就都只是随便举一下项目中的实际情况为例,项目是用MFC开发,使用了Codejock的Xtreme Toolkit Pro界面扩展库。
> > 重复代码。有3处计算MD5的实现,分别由3个开发人员完成,大概实在是这种实现的代码在网上太容易找到了。另外有一个特性,可以与另一个服务进行
> > 文件的上传、下载、更新、同步,而文件因为类型不同,做这些操作时某些细节有细小的差别,但实现中却是为每一类文件具体而完整都实现了一遍这些操作。
> > 过长的函数。有的开发人员就是习惯性地写出长函数。整个项目中,圈复杂度超过100的有4个函数,超过20的不知道是几十还是上百个。
> > 过大的类。有一个类的cpp文件,是18000行,另外有一个类的cpp文件是10000行。还有CMainFrame类的cpp文件,用
> > Source Insight打开后,在列出函数列表的窗口中显示"Too complex to parse"。
> > 过长的函数列表。有一个cpp文件中共9个函数实现,每个函数的参数都超过7个,而且含义晦涩,自从原创人员两年前离职后,没人敢去动那块代码。
> > 发散式变化。前面提到的一个18000行的cpp文件,是一个视图的实现。如果要给该视图的右键菜单中新增加一个菜单项,并进行响应,需要修改不知
> > 多少个函数,记得曾经有个开发人员,花了一周时间都在为了一个新增的菜单项。添加代码没花多少时间,时间花在添加后,因此引发的问题上。
> > 霰弹式修改。有两个模块都需要一个高亮显示语法关键字的编辑功能。有一个基本的控件封装类,但要修改一些代码时,总是要很小心地去从头检查一遍另一
> > 模块的实现是否受影响。我的理解是,这个控件封装类的抽象不够通用,或者两个模块的相似度并不高。
> > 基本型别偏执。这样的代码在项目中不好找,不过有类似的。项目中使用MSXML操作xml数据,在各个模块的实现中,都直接聚合了一堆MSXML的
> > 接口指针,操作xml的方法,和业务逻辑、界面响应完全混合在一起。
> > Switch结构。很多处又大又长的switch结构。
> > 冗余累赘类。有两个(派生)类过于考虑以后的扩展性,而那种扩展性的需求至少在未来2、3年内是遇不上的。
> > 夸夸其谈未来性。有一个快捷键处理模块,从项目刚开始就已经实现完成,但后来一直没被用过。项目没有开始实际编码前,超过5个人,花了2个月制订了
> > 各个模块需要暴露的COM接口,结果到现在3年了,真正实现的接口也才10个左右。
> > 中间转手人。CMainFrame类已经成了各个模块用来转发消息的场所。一个重要的原因是界面与业务逻辑耦合,很多业务处理需要
> > MainFrame转发到相应的界面实现类中进行处理。
> > 狎昵关系。无论是各个Pane还是MDIClient,都与CMainFrame存在着这种双向依赖关系。
> > 异曲同工的类。两个有交互的模块,居然各自定义了一组数据结构,用来描述现实世界中的同一种事物,中间又由CMainFrame来完成这两组数组结
> > 构之间的转换。
> > 纯数据的类。很多时候,为了向线程函数传递一些数据(超过一个DWORD的量),就专门定义一个纯数据的类。
> > 被拒绝的遗赠。两个平行的模块,一个类是从另一个类继承过来的,而明明有很多那被继承的类的功能,在派生类中是不需要的。呃,被继承的就是那个
> > 18000行的类。另外还有那两个需要编辑功能的模块,曾经居然也是一个类从另一个类直接继承,导致在派生类中变成不需要什么功能,就加些代码,把那部
> > 分功能屏蔽掉。
> > 过多的注释,有一个开发人员,喜欢在自己编写的函数开头部分写上几十行注释,呃,全是算法描述和伪代码。
> > 在公司4年,我参与过的略有规模的项目,除了这个外,另外有一个,基本是独自一人完成,代码量最高峰是7万行,后来路过不断的重构,在仍然有新特性
> > 增加的前提下,代码量缩减到4万多,现在回头看来,这个项目中代码的坏味道似乎少一些,但质量却也不行,崩溃经常发生,其他业务逻辑有问题的也不少。
> > 所以,我就很是困惑啊,别人的项目是怎么样的情况?