组织好自己的代码

想移植一程序，看到g打头的变量，格外头疼，本只想移两个文件，每个g_XXX带出一堆泥

接着是CList之类的，也让老衲头疼不已，这些东西其实可以用std::list代替.这个可能属于个人习惯问题

但std的东西确实要比atl的东西通用性要强。

除了日志系统之外(如果设置日志级别的变量，用global吧,没事)，绝对不要在程序在任何地方使用全局变量

(当然如果用到第三方回调，而回调没有提供上下文参数的情况，只能使用全局变量了，相信这种情况会比较少)

笔者曾经在很多项目需要用到同事的代码，被全局变量弄得头疼不已。

全局变量，已经从笔者写的程序中消失了（除了日志模块之外），哈哈

同理：

单例模式也尽量不要用，形式不同，本质也同于全局变量

宏，尽量控制宏的作用范围，形式不同，它的危害同于全局变量

控制每个变量的作用范围，甚至是一个类的成员变量。尽量少的耦合，才能让代码更好维护。

如果代码不是与windows关联很强，尽量使用std里的东西，CList之类的，让人头疼不已，难以移植

也就是尽量用c/c++标准里的东西

尽量少的煸出，导出的接口应简单明了，并加上注释，使用接口的人其实是个用户，如还要关心接口实现，

只能自己重写一个了。

相同或者相似的逻辑应封装，但又不可过度封装，呵呵，这个比较难以把握，笔者审视自己早期写的代码

发现有些是封装过度了，显得笨重。

注释：

没有注释的程序让人迷惑，尽量加上注释，笔者已经形成注释强迫症，

先写注释，再写代码，注释不是万能的，没有注释是万万不能的。

谁分配，谁释放问题

这种事c++已经干得不错了，没有gc, c++被其它语言攻击得体无完肤，

跟c比，又不够简洁，伤不起啊，但c++依然是好东西，呵呵。

归根到底，还是个人习惯的问题，程序崩了，漏了，还是只能怪自己编码不够

谨慎。管好分配释放问题，比起诅咒c++，才是解决问题的态度。

没有不好的语言，只有不好的编程习惯。

好好提炼写过的代码，剥离出能复用的，让自己活得轻松一点。

当然也可以在一些第三方库上建立开发，但不如自己的用得顺手，出bug也容易调。

不提倡重造轮子，但有自己的通用lib总是一件好事。

自己弄出来的东西，如果适用且实用，那就用吧。