第5条:一个实体应该只有一个紧凑的职责
单一职责原则。这个原则并不那么容易执行,即使是STL这样的程序库,也一样会犯违反该原则的错误。在这里,举了两个违反这一原则的著名实现:realloc和stl 中的basic_string。不过,对于basic_string,我想比起MFC中的CString还是好了不少。在《Exceptional C++ style》中,对basic_string作了剖析,并且得出一个普遍的原则:尽量将函数实现为独立的函数而不是成员函数。
尝试用一句话来说明一个模块的功能,既不多,也不少。如果无法用这样的一句话加以概括,那么重新考虑规划该模块的职责。
第6条:正确、简单和清晰第一
简单的说,坚持KISS原则:正确优于速度,简单优于复杂,清晰优于机巧,安全优于不安全。
不要滥用匿名变量,合理使用命名变量。当然,这不是说连vector().swap(other)这样的惯用法也要排斥。
重构技术是改善代码可读性的有效手段。
第7条:编程中应知道何时和如何考虑可伸缩性
从字面上来看,这差不多等于外交辞令。答案无非是“适当的”时候“适当地”考虑可伸缩性。这非常依赖于软件工程师的经验和知识。所以,本条目也“适当地”回避了那种缺乏营养的教导,着重讨论算法复杂度的选择问题。
基本上,线性复杂度可以作为一个算法是否可选的分界点。值得花费精力避免选择差于线性复杂度的算法,而不差于线性复杂度的算法则可以接受。所以,把性能放在嘴边的兄弟们注意了,你的精力可别放错了地方,高德纳言犹在耳:不成熟的优化是程序设计中的万恶之源。必要时,先努力优化复杂度(选择好的算法----算法无用论者,去面壁!)。
顺便提一句排序算法,通用排序算法的复杂度最好是O(NlgN),但是特定领域完全可以有更好复杂度的算法。
第8条:不要进行不成熟的优化
“不成熟的优化是程序设计中的万恶之源” ----高德纳引用的这句话这本书中出现了若干次,高德纳在他的不朽名著《计算机程序设计艺术》中也一再强调了这一点,还说他以前程序中的许多错误都是关于不成熟优化的。看来,唯一在诱惑面前没有堕落的,只有耶稣,即使是大师也无法抗拒。既然如此,建议把下面的话放在电脑桌面上:
第9条:不要进行不成熟的劣化
什么是不成熟的劣化呢?典型的有:
然而,要区别不成熟的优化和不成熟的劣化之间,需要足够的训练和基础知识,这些知识可以从《Effective C++》,《More Effective C++》《Exceptional C++》《More Exceptional C++》中获得。
第10条:尽量减少全局和共享数据
全局数据是应该努力避免的,它导致两个问题:名字污染和远程耦合。类的公有静态变量只是解决了名字污染问题,并没有解决远程数据耦合问题。同样,Singleton模式也存在远程耦合问题。
全局数据通常就意味着共享,共享数据则意味着关系,意味着复杂性。再多线程中,对共享数据的访问通常都需要串行化。
关于变量,一个比较深刻的看法是:一个算法使用的变量(命名的和匿名的)越少,就越好。这个变量包括局部变量。
第11条:信息隐藏
对于一个类,决不要将数据公开(数值聚合的struct 例外),也不要返回指向内部数据成员的指针或引用供外部代码修改。通过提供抽象,我们将获得插入不变式检查的能力。
第12条:懂得何时和如何进行并发性编程
这个问题主要是考虑多线程和多进程的编程,我期待着并行程序设计进入C++的领域。要编写正确、安全的多线程代码并不简单,特别是考虑到可移植性时,更是如此。
不过,本条目的题目太大了,很难在一个条目中描述完整,只能概述几个要点:
第13条:确保资源为对象所拥有。使用显式的RAII和智能指针
好像是在《Imperfact C++》中说过:仅仅因为有RAII就值得使用C++。C++/CLI也强调引入确定性析构,确定性析构正式RAII得以实现的基础之一。通过RAII我们能够得到的远远超出一般程序员的想象,在讨论异常安全代码时,将进一步见识RAII的威力。
在实现RAII时,需要小心复制构造和赋值,编译器的版本可能并不正确。另外,需要确保资源为对象所有,不要在一行分配一个以上的资源。下面的代码是不安全的:
Fun(shared_ptr<Widget>(new Widget), shared_ptr<Widget>(new Widget));
取而代之的正确方法是:
shared_ptr<Widget> sp1(new Widget), sp2(new Widget);
Fun(sp1, sp2);
http://blog.csdn.net/wingfiring 非典型秃子
单一职责原则。这个原则并不那么容易执行,即使是STL这样的程序库,也一样会犯违反该原则的错误。在这里,举了两个违反这一原则的著名实现:realloc和stl 中的basic_string。不过,对于basic_string,我想比起MFC中的CString还是好了不少。在《Exceptional C++ style》中,对basic_string作了剖析,并且得出一个普遍的原则:尽量将函数实现为独立的函数而不是成员函数。
尝试用一句话来说明一个模块的功能,既不多,也不少。如果无法用这样的一句话加以概括,那么重新考虑规划该模块的职责。
第6条:正确、简单和清晰第一
简单的说,坚持KISS原则:正确优于速度,简单优于复杂,清晰优于机巧,安全优于不安全。
- 程序必须为阅读它的人编写,只是顺便用于机器执行 * 编写程序应该以人为本,计算机第二
- 计算机系统中最便宜、最快速、最可靠的组件都还不存在
- ......简单设计的重要性怎么强调也不过分
- 使一个正确的程序变快,比使一个快速的程序正确要容易的多
- 避免使用程序设计语言的冷僻特性,应该使用最简单的有效技术
不要滥用匿名变量,合理使用命名变量。当然,这不是说连vector().swap(other)这样的惯用法也要排斥。
重构技术是改善代码可读性的有效手段。
第7条:编程中应知道何时和如何考虑可伸缩性
从字面上来看,这差不多等于外交辞令。答案无非是“适当的”时候“适当地”考虑可伸缩性。这非常依赖于软件工程师的经验和知识。所以,本条目也“适当地”回避了那种缺乏营养的教导,着重讨论算法复杂度的选择问题。
基本上,线性复杂度可以作为一个算法是否可选的分界点。值得花费精力避免选择差于线性复杂度的算法,而不差于线性复杂度的算法则可以接受。所以,把性能放在嘴边的兄弟们注意了,你的精力可别放错了地方,高德纳言犹在耳:不成熟的优化是程序设计中的万恶之源。必要时,先努力优化复杂度(选择好的算法----算法无用论者,去面壁!)。
顺便提一句排序算法,通用排序算法的复杂度最好是O(NlgN),但是特定领域完全可以有更好复杂度的算法。
第8条:不要进行不成熟的优化
“不成熟的优化是程序设计中的万恶之源” ----高德纳引用的这句话这本书中出现了若干次,高德纳在他的不朽名著《计算机程序设计艺术》中也一再强调了这一点,还说他以前程序中的许多错误都是关于不成熟优化的。看来,唯一在诱惑面前没有堕落的,只有耶稣,即使是大师也无法抗拒。既然如此,建议把下面的话放在电脑桌面上:
让一个正确的程序更快速,
比让一个快速的程序正确,要容易的太多太多。
比让一个快速的程序正确,要容易的太多太多。
第9条:不要进行不成熟的劣化
什么是不成熟的劣化呢?典型的有:
- 在可以通过引用传递的时候,却定义了通过值传递参数。
- 在使用前缀++操作符很适合的场合,却使用后缀版本。
- 在构造函数中使用赋值操作而不是初始化列表。
然而,要区别不成熟的优化和不成熟的劣化之间,需要足够的训练和基础知识,这些知识可以从《Effective C++》,《More Effective C++》《Exceptional C++》《More Exceptional C++》中获得。
第10条:尽量减少全局和共享数据
全局数据是应该努力避免的,它导致两个问题:名字污染和远程耦合。类的公有静态变量只是解决了名字污染问题,并没有解决远程数据耦合问题。同样,Singleton模式也存在远程耦合问题。
全局数据通常就意味着共享,共享数据则意味着关系,意味着复杂性。再多线程中,对共享数据的访问通常都需要串行化。
关于变量,一个比较深刻的看法是:一个算法使用的变量(命名的和匿名的)越少,就越好。这个变量包括局部变量。
第11条:信息隐藏
对于一个类,决不要将数据公开(数值聚合的struct 例外),也不要返回指向内部数据成员的指针或引用供外部代码修改。通过提供抽象,我们将获得插入不变式检查的能力。
第12条:懂得何时和如何进行并发性编程
这个问题主要是考虑多线程和多进程的编程,我期待着并行程序设计进入C++的领域。要编写正确、安全的多线程代码并不简单,特别是考虑到可移植性时,更是如此。
不过,本条目的题目太大了,很难在一个条目中描述完整,只能概述几个要点:
- 参考目标平台文档,了解该平台的同步化原语。
- 最好将平台原语用自己设计的抽象包装起来
- 确保正在使用的类型在多线程程序中使用是安全的
第13条:确保资源为对象所拥有。使用显式的RAII和智能指针
好像是在《Imperfact C++》中说过:仅仅因为有RAII就值得使用C++。C++/CLI也强调引入确定性析构,确定性析构正式RAII得以实现的基础之一。通过RAII我们能够得到的远远超出一般程序员的想象,在讨论异常安全代码时,将进一步见识RAII的威力。
在实现RAII时,需要小心复制构造和赋值,编译器的版本可能并不正确。另外,需要确保资源为对象所有,不要在一行分配一个以上的资源。下面的代码是不安全的:
Fun(shared_ptr<Widget>(new Widget), shared_ptr<Widget>(new Widget));
取而代之的正确方法是:
shared_ptr<Widget> sp1(new Widget), sp2(new Widget);
Fun(sp1, sp2);
http://blog.csdn.net/wingfiring 非典型秃子