C++博客-love in C++, live on MFC-随笔分类-C++ Coding Standards

Make header files self-sufficient的一个例子

flyingxu — Fri, 23 Jun 2006 12:56:00 GMT

C＋＋编程规范中第23条中说：
If one header file won't work unless the file that includes it also includes another header, that's gauche and puts unnecessary burden on that header file's users.
呵呵，英语有点拗口，后面举的例子也都是模板的例子。我倒是遇到过一个实际的例子，简化后如下：

//a.h
class A
{
int a;
};

//b.h
//注意：b.h并没有include a.h
class B
{
A a;
};

用的时候怎么用呢？比如在main.cpp中想用class B

//main.cpp
#include "a.h"
#include "b.h"
//
B b;
//
//do something on b

可以看到，main为了使用B，还得包含a.h，这就是上面一段英语说的：
如果一个头文件（b.h）不能工作，除非包含它（b.h）的文件（也就是main.cpp）也包含另一个头文件（a.h）...

hehe，当我第一次遇到这种情况时，想了半天也想不明白为什么我明明包含了b.h还是不能用B啊

那么，正确的写法应该是什么呢？
在类B的作者在设计B的时候，就应该想到用户只需要#include "b.h"就可以使用这个class B。所以，在b.h文件中，应该写明#include "a.h"，而不是让用户在main.cpp中去include "a.h"

:)

flyingxu 2006-06-23 20:56 发表评论

用返回类型BOOL替代函数返回类型void

flyingxu — Wed, 17 May 2006 08:12:00 GMT

在写函数的时候,很多函数只是设置某个变量然后做一些其他的相应的处理,比如:

void CInstruction::SetName(const CString& strName)
{
    m_strName = strName;

            //some other operations
    if(!IsRed())
    {
        //...
    }
}

这样的函数,返回类型为void顺理成章.

但是,随着程序继续往下写,需要处理的情况越来越复杂,这个时候,发现SetName这个函数,返回void已经不够用了,因为可以需要知道SetName这个函数调用有没有成功,因为可能传入的strName不一定是合法的,如果调用SetName函数没有成功,可能要继续调用别的函数,这个时候,可能就要讲返回类型改为BOOL.

而后来继续想,一个函数的返回值,应该更加充分的利用,调用一个函数时,就该充分的利用它的返回值;而在写一个函数时,也应该注意到这一点.如果实在没有什么值好返回,就返回TRUE

所以,对于函数,如果在设计时准备把返回类型定为void,其实可以改为BOOL
1)最初可能没有用,但情况会越来越复杂
2)充分利用函数的返回值

flyingxu 2006-05-17 16:12 发表评论

尽量用代码来替代资源中的属性

flyingxu — Wed, 17 May 2006 06:17:00 GMT

资源中的属性,是指写MFC程序时VC IDE的resource编辑器中可以设定的各种属性,比如WS_EX_TRANSPARENT或者LVS_REPORT.
而这些属性,都是可以用代码在程序初始化后加上去的,比如在OnInitDialog() 或者OnCreate()函数中.

从方便性来说,肯定是在资源中设置这些属性更加方便,但是..
我遇到一种情况,在我的程序中,有两个rc文件,分别是中文和英文,这个时候,就发生了在英文资源中设置了属性修正了一个bug但是在中文版的资源中忘记设置,bug依然存在.而如果是在在代码中加上类似的代码:

m_CrossRefTab.ModifyStyleEx(0,WS_EX_TRANSPARENT);

资源文件不用改变,而且修正了所有的问题.

所以,我觉得,应该尽量用几行代码来替代在资源中的设定属性

flyingxu 2006-05-17 14:17 发表评论

code review 把代码投影在墙上

flyingxu — Sun, 09 Apr 2006 13:37:00 GMT

锋锋说：
把代码投影在墙上，几个人坐下来一起评论也是有效的方法

呵呵，我觉得很cool啊，可惜现在我不是老板，等我哪天成老板了，就这么做

flyingxu 2006-04-09 21:37 发表评论

Is Hungarian notation obsolete?

flyingxu — Wed, 05 Apr 2006 11:45:00 GMT

书上说匈牙利命名法已经过时了，我不这样认为。

有人认为现在编译器已经可以很好的检测出类型的不匹配，或者IDE中可以很快的看到类型，所以在c中可能需要，在C＋＋（强类型语言）中就不需要了。
C++ made it harder to do that without wicked casting and the compiler catches most of those kind of errors. So, I agree with the previous poster that it's now redundant.
Also, modern IDEs allow you to hover the cursor over a variable and show you the variable's definition.

不过我觉得代码不是写给编译器看的，而是写给人看的，这里就有self-documenting和readability的问题。
很明显，如果你看到nIndex 或者strFile或者wndNext，就可以很快知道分别是int CString CWnd类型，而不用回头去看变量定义，这样，看代码时就会很快。
而且，对于MFC程序员来说，更重要一些，因为MFC里面的变量都是用匈牙利命名法的。
If you're programming C++/MFC you're better sticking to hungarian for consistency with the class library & Win32 API declarations.
微软的约定，就是标准了

不过，书上提到在泛型编程中不需要，现在体会还不深，可能是对的。

今天(2006 04 13碰巧看到codeproject的一个vote),结果如下

Option	Votes	%
Pascal Cased	171	10.6
camel Cased	702	43.4
Fixed letter prefix (eg lLocal)	81	5.0
Hungarian prefix (eg strLocal)	481	29.7
Scope prefix (eg l_Local)	36	2.2
Scope and Hungarian prefix (eg l_strLocal)	125	7.7
Responses	1618	�

Hungarian Notation排第二.
cp上面有两个链接
Conversations: Hungarian wartHogs (http://www.cuj.com/documents/s=7989/cujcexp1911hyslop/hyslop.htm)
号称这篇文章就已经明白的说HN过时了(作者也是c++ coding stardard的作者).
如果不用HN,那么应该用什么样的命名规则呢?
Naming Guidelines(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconNamingGuidelines.asp)
.Net下的推荐,也许别的地方也可以用.

flyingxu 2006-04-05 19:45 发表评论