C++良好代码风格之我见 - 兼谈boost的工程实用价值

原创 2009年05月15日 00:49:00

TopLanguage上,一个关于“boost的理念和工程实用价值”的讨论(http://groups.google.com/group/pongba/browse_thread/thread/7501f6ff39b7ff0)吸引了很多人。我这里谈谈我的看法。

 

无疑,boost是很优秀的库(确切的说,是库的集合)。但是我在介绍我的StdExt库的来由时,曾经毫不客气的说,boost 走错了方向。这其中的原因,归结于我对什么才是C++良好代码风格的看法。

 

其一,简单是美。如果一件事情可以用简单的方法去完成,就不要仅仅为了方便花十分的力气去制造语法糖。boost中属于这方面的例子很多,如:boost::lambda, boost::shared_ptr, BOOST_FOREACH等。对于boost::lambda,BOOST_FOREACH,我倾向于在语言层面去引入相关的机制。在没有语言的机制下,多写几行代码完全不是什么难事(boost::lambda完全可以写一个仿函数类来搞定,而且调试方便,用lambda虽然代码少,但是失去了调试的便捷,其实是得不偿失;BOOST_FOREACH则完全可以用标准的for(it = cont.begin(); it != cont.end(); ++it) 搞定)。至于boost::shared_ptr算不算是一种语法糖,还是一种有效的内存管理机制,争议比较大。我从来不认为智能指针可以解决内存泄漏问题(在一个相对简单、封闭的工程环境里使用确实有效,但是并不能适应更复杂的环境),事实上除了COM中我会使用智能指针,其他情况下绝少用。

 

当然,语法糖有时候可能是唯一选择,例如boost spirit、boost xpressive。这两个库目的类似,都是实现一个静态正则文法(第3个类似的库,是我写的TPL)。语法糖在描述正则文法时显得优雅。又如,假设我们要实现一个矩阵(matrix)运算库,虽然add函数也可以做加法,但是用operator+来做矩阵加法显然看起来要优雅许多。

 

其二,项目应形成功能闭包。任何一个项目,都应该有一个明确的目标和问题域。由此而延伸,项目的功能集合应该有个界限,而不是不断膨胀下去。从boost一个个子库看,没有问题。但是从boost这个总体来看,非常有问题,因为它只是一个无主题的大杂烩。没有做物理的子库划分和目标限定,这是我认为boost最为失败的一点。

 

其三,最小外部依赖原则。在我们实现一个项目时,需要谨慎评估我们将依赖哪些外部库,并尽可能将这种依赖最小化。如果我们需要的组件和某个库有非常高的重叠度时,我们说,我们需要这个库;而相反,如果我们只是需要某个库中的一个辅助类时,我们不妨拿来主义,将该类的实现迁移到本项目,而不是不假思索地引用这个库。

 

最小外部依赖原则不单单适用于项目,也适用于单个源代码文件(cpp)的实现。事实上,一个cpp会包含哪些头文件,这些头文件是否真的是这个cpp的正常依赖,同样需要谨慎对待。也许没有工程依赖那么严重,但是这方面的认真考虑将提升你的设计水平。

 

最小外部依赖原则,是导致boost不敢被广泛采纳和使用的重要原因。还是因为boost是个大杂烩,没有进行子库划分和目标限定,这让希望用boost的人无可适从,不能很清晰地评估boost是否适合自己的项目。

 

谈谈良好的编码风格

能写出结构精巧的代码是一件令人羡慕的事情,能写出解决复杂问题模型的算法是一件令人羡慕而又佩服事情。虽然未必所有人能做到这些,但是每一个对代码有信仰的人至少要做到语法使用合理、代码简洁、逻辑清晰、变量的...
  • lanyuxinkong
  • lanyuxinkong
  • 2015年08月27日 16:26
  • 1737

向google学习良好的C++代码风格-(1)概述

  • nanyu
  • nanyu
  • 2009年07月25日 09:40
  • 2953

代码风格还是很重要的

我看过不少人写的程序——其中不乏一些写了多年程序之人,其代码之凌乱让人不忍再往下看。我不知道各位自己有没有这样的经历:一年半载之后,自己原来写的程序就完全看不懂了。如果写程序只是为了交作业,或者临时测...
  • richardbao2000
  • richardbao2000
  • 2006年09月19日 12:05
  • 3022

什么样的代码算是‘良好的代码风格

大家谈谈对良好的代码风格的理解呗!! 大家都会说是:易理解,易修改,易扩展等等的代码就叫良好的代码风格, 但是,要做到什么地步才能达到如此境界呢?? msup的老师 刘捷说:简单,沟通,...
  • u014266437
  • u014266437
  • 2014年03月21日 20:46
  • 306

Google Java编程风格指南(献给那些没有良好编码习惯的程序员们)

作者:Hawstein出处:http://hawstein.com/posts/google-java-style.html声明:本文采用以下协议进行授权: 自由转载-非商用-非衍生-保持署名|Cre...
  • changemyself
  • changemyself
  • 2014年03月26日 11:14
  • 8197

扫盲 DNS 原理,兼谈“域名劫持”和“域名欺骗/域名污染”

前天下午(1月21日),咱们天朝发生了全国性的互联网故障,导致大量国内网站无法访问。这次故障说白了就是一次全国性大范围的域名污染。所以俺借此机会,给大伙儿扫盲一下 DNS 的常识。既然是扫盲 DNS,...
  • u010889861
  • u010889861
  • 2016年12月07日 15:03
  • 1140

良好的程序设计风格是成功的一半

良好的程序设计风格是成功的一半        曾经,老师一次又一次的告诫我们,要有良好的程序设计风格,直到,与他人一起协作开发一款小软件时,看不懂别人写的代码(没有注释,书写混乱),才深刻理解了老师...
  • u012027907
  • u012027907
  • 2013年11月30日 18:23
  • 1851

C++良好的代码风格

1, 命名,简单就是美,简单易记,望文生义,并且风格要保持一致。 2, 注释 3, 合理的缩进和版面布局 4, 遵守基本的编程约定。 5, 功能分类的函数等分类好。...
  • HelloDan
  • HelloDan
  • 2010年05月07日 17:17
  • 461

《Word排版艺术》读后感——兼谈与LaTeX的比较

《Word排版艺术》读后感——兼谈与LaTeX的比较 我有两年多的LaTeX使用经验,用它排实验报告、毕业论文和书籍(半本);Word的使用时间长一些,但真正用好也不过是近一两年的事。这两个软件我都用...
  • Solstice
  • Solstice
  • 2004年11月19日 12:52
  • 22858

OC代码风格规范

一些基本的代码风格就不多说了,说下不怎么在意的代码规范问题。 【1】 局部变量不应该包含下划线命名。 【2】变量命名应该如 NSString *text 而不是 NSString* text 或者 N...
  • WiKi_Su
  • WiKi_Su
  • 2016年01月28日 15:20
  • 617
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:C++良好代码风格之我见 - 兼谈boost的工程实用价值
举报原因:
原因补充:

(最多只允许输入30个字)