命名法是个我不想再纠结的东西，不过最近又遇上了…
碰巧过完年，脑子锈掉了，居然读不懂自己年前写的代码了。我向来奉行“代码即注释”原则，也就是说…几乎不写注释…完全依靠函数和变量命名的含义来表达代码的意图和思路，除非真有复杂到需要注释的地方，例如莫名其妙的需要多线程同步的地方之外，其余一律不写注释。不过反作用就是，年前那阵子贪玩，没认真好好写代码，导致命名有点糟糕，过了年回来再读就有点绕人了…

一边改那些变量的名字，一边就遇到这个命名法的问题。我还在用匈牙利前缀，整数用n，浮点数用f，字符串用sz。现在需要自己增加几个自己的规则。
iterator类型，我原先用it做前缀，打出的代码看上去非常丑陋，例如：

for(std::vector<Phone>::iterator itPhone = phoneList.begin(), 
    itPhoneEnd = phoneList.end(); itPhone != itPhoneEnd; ++itPhone) {
  //...
}

单纯就觉得这两个字母放在前面不搭，不美…现在我用小写t做前缀，好看多了。

for(std::vector<Phone>::iterator tPhone = phoneList.begin(),
    tPhoneEnd = phoneList.end(); tPhone != tPhoneEnd; ++tPhone) {
  //...
}

当然了，这是古董代码了，有了foreach，这样的代码已经可以进垃圾堆了。不过难免用到iterator的时候俺就该记得用这个t前缀。还有就是项目里的代码我不想霰弹枪一起动，先这样放着比乱改安全很多…

受这个启发，typedef出来的变量类型用大写T前缀，例如

typedef std::vector<Phone> TPhoneList; 
for(TPhoneList::iterator tPhone = phoneList.begin(), 
    tPhoneEnd = phoneList.end(); tPhone != tPhoneEnd; ++tPhone) {
  //...
}

我喜欢typedef出几个项目中常用的容器类型。仅仅到容器类型，而iterator类型直接使用Type::iterator引用，而不进一步typedef。这样恰好保持代码的简洁程度适中，容易理解。

std::string类型用str前缀，而raw string类型(0结尾的字节序列)用sz类型，从而区分两者。这一点通常不重要，但是当你使用printf的时候:

std::string strName = "Peter Pan";
printf("hello %s\n", strName.c_str());

str前缀会提醒你记得用上c_str()方法。事实上这个问题惹恼我好几回了，最倒霉的一回是同事从北京打电话跟我联调，他那边输出的log出现乱码，而我这边丝毫没有，他通过IM给我看输出，告诉我printf打出来的。我不相信我的眼睛，好像就是变戏法。直到调了好久他才突然说，噢！忘记.c_str()了！
当然这仍旧不是好方法。真正问题出在printf不是一个类型安全的函数，编译器无法为你做编译时检查。但是类似printf, sprintf这类函数使用方便，即使最终产品不使用，调试阶段输出log还是会经常使用的。这个时候区分std::string和raw string就变得有意义了。

堆上空间使用p前缀，而栈上空间不使用。这里主要说的是数组。主要目的是当你使用p前缀的变量时候，就会提醒着自己记得思考该让谁delete掉他这个问题了。
例如

char szName[] = "Peter Pan";
char* pszName = new char[10];

我忽然在思考，是不是应该用q前缀来命名那些堆空间的拥有者，而用p前缀来命名那些弱引用。但如果是这样，那么不明拥有者，或者拥有者变更的情况怎么办？再引入一个ps前缀(p_shared_)？也许会弄得太复杂了。也许既然想了这么多，还不如一开始就用智能指针。为什么我不想引入智能指针？我不想引入复杂度。因此如果仅仅为了区区命名而导致复杂度增加，还不如一开始就简单化。所以还是所有指针都用p前缀。到底谁负责，自己好好想清楚。我想，引导读程序的人思考，比用带有暗示意味却可能是错误的命名要好得多。
在使用弱引用时，我经常使用的名字，例如pRead, pWrite, pBegin, pEnd, pCurrent, 等等，这些名字具有强烈的暗示性，说明他们是弱引用，正常人是不会去释放这样名称的变量的，更不会给这样的变量开辟空间。而另一些名字则比较危险，比如pNext, pChild, pParent, pSibling。这些名字的变量，可能你需要去释放他，可能你不需要(例如这是一个树状数组)。这个时候注释是必须的，否则很可能今天写的代码，明天就忽然觉得，不对，这里既然pNext被移动了，那么原来那个东西就应该先释放掉。然后Boom!程序崩溃。还好，现代程序员几乎不需要自己编写类似这样的基础数据结构，直接用酒精久经考验的标准库就行了。而且，就算偶尔碰上了，只要仔细调试通过，以后几乎不会再去改他了(毕竟最多的改动还是在上层嘛)。所以不算什么太大的麻烦。

呜，暂时想记录的就这么多了，给以后想要偷懒的自己看。