代码设计规范

一、 函数
现代程序设计语言中的绝大部分功能,都在程序的函数(Function,Method)中实现,关于函数最重要的原则是:只做一件事,但是要做好。


二、 错误处理

80%的程序代码,都是对各种已经发生和可能发生的错误的处理。

如果错误会发生,那就让程序死的地方离错误产生的地方越近越好。


1.参数处理
在DeBug版本中,所有的参数都要验证其正确性。在正式版本中,从外部(用户或别的模块)传递过来的参数要验证其正确性。
2.断言
如何验证正确性?那就要用Assert(断言)。断言和错误处理是什么关系?
当你觉得某事肯定如何,你可以用断言。
Assert (p != NULL);
然后可以直接使用变量p;

如果你认为某事可能会发生,这时就要用错误处理。如:

     p = AllocateNewSpace(); // could fail
     if (p == NULL){ 
        // error handling.
     }else{ 
        // use p to do something
     }

三、 如何处理C++中的类

注意,除了关于异常(Exception)的部分,大部分其他原则对C#也适用。

1.类
(1)使用类来封装面向对象的概念和多态(Polymorphism)。
(2)避免传递类型实体的值,应该用指针传递。换句话说,对于简单的数据类型,没有必要用类来实现。
(3)对于有显式的构造和析构函数,不要建立全局的实体,因为你不知道它们在何时创建和消除。
(4)只有在必要的时候,才使用“类”。
2.Class vs. Struct
如果只是数据的封装,用Struct即可。
3.公共/保护/私有成员Public、Private和Protected
按照这样的次序来说明类中的成员:public、protected、private
4.数据成员
(1)数据类型的成员用m_name说明。
(2)不要使用公共的数据成员,要用inline访问函数,这样可同时兼顾封装和效率。
5.虚函数Virtual Functions
(1)使用虚函数来实现多态(Polymorphism)。
(2)只有在非常必要的时候,才使用虚函数。
(3)如果一个类型要实现多态,在基类(Base Class)中的析构函数应该是虚函数。
6.构造函数Constructors
(1)不要在构造函数中做复杂的操作,简单初始化所有数据成员即可。
(2)构造函数不应该返回错误(事实上也无法返回)。把可能出错的操作放到HrInit()或FInit()中。

     class Foo{
        public:
               Foo(int cLines) { m_hwnd = NULL; m_cLines = cLines}
               virtual ~Foo();
               HRESULT HrInit();
               void DoSomething();
        private:
               HWND m_hwnd;
               int m_cLines;
     };
7.析构函数 (1)把所有的清理工作都放在析构函数中。如果有些资源在析构函数之前就释放了,记住要重置这些成员为0或NULL。 (2)析构函数也不应该出错。 8.New和Delete (1)如果可能,实现自己的New/Delete,这样可以方便地加上自己的跟踪和管理机制。自己的New/Delete可以包装系统提供的New/Delete。 (2)检查New的返回值。New不一定都成功。 (3)释放指针时不用检查NULL。 9.运算符(Operators) (1)在理想状态下,我们定义的类不需要自定义操作符。只有当操作符的确需要时。 (2)运算符不要做标准语义之外的任何动作。例如,“==”的判断不能改变被比较实体的状态。 (3)运算符的实现必须非常有效率,如果有复杂的操作,应定义一个单独的函数。 (4)当你拿不定主意的时候,用成员函数,不要用运算符。 10.异常(Exceptions) (1)异常是在“异乎寻常”的情况下出现的,它的设置和处理都要花费“异乎寻常”的开销,所以不要用异常作为逻辑控制来处理程序的主要流程。 (2)了解异常及处理异常的花销,在C++语言中,这是不可忽视的开销。 (3)当使用异常时,要注意在什么地方清理数据。 (4)异常不能跨过DLL或进程的边界来传递信息,所以异常不是万能的。 11.类型继承(Class Inheritance) (1)当有必要的时候,才使用类型继承。 (2)用Const标注只读的参数(参数指向的数据是只读的,而不是参数本身)。 (3)用Const标注不改变数据的函数。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结