当你写下第一行代码，命名风格的问题就找上来了，我个人接触过几种风格的：
１，MFC风格
    class CClassName
    {
        public:
             void DoSomething();
        private:
             CString m_strName;
     };
2，linux风格
　　class class_name
    {
         public:
            void do_something();
         private:
            std::string name_;
    };
　　class class_name_t
    {
         public:
            void do_something();
         private:
            std::string name_;
    };
3，Java风格
    class ClassName
    {
         public:
              void doSomething();
         private:
              std::string name;
    };
这里关注的差异部分是：1，名称中是否使用类型前缀或后缀；2，怎样使用大小写。
　　风格1（MFC风格、匈牙利命名风格）带来的问题是：导致命名复杂化（m_lpszName？），每次写个变量名都要经过n道工序（中文->英文->类型提取->最后的名称），一个类型变化时（如：要用结构代替内置类型，typedef）是不是得发个重大更新重大升级啊，要不然怎么对得起程序中大范围的名称替换，要是用svn的版本比对一定可以看到状观的景像。
　　风格2（linux风格）问题是：带后缀总是显得不美观（看看stl的原代码），用户成了命名规范的二等公民（看看boost库），通用直观的好名字都认库占了。其实c++中成员变量带后缀是好理解的，它可以避免和参数名称冲突，如下所示：
　　class class_name
    {
       public:
           class_name(std::string name)
             :name_(name)
          {
          
           }
          void set_name(std::string name)
         {
             name_ = name; 
          }
       private:
           std::string name_;
    };
    //当成员name_命名为name时，在set_name函数中name = name将是参数的自赋值。
成员变量带后缀可接受是因为我们认为没有人会引用它（看到它），但当序列化时，它的名称会被用户见到，另外成员变量也可能是公有的，如一个C结构带了一个辅助使用的构造函数时。那么参数名称加下划线怎么样？我这么干过，不过更不好，因为它会污染你IDE的智能提示以及用doxygen生成的文档。
类型名后加_t也是好理解的，除了表明这是一个类型外，可以避免与该类型的实例名称相冲突，有人会说实例名称用简写不就行了吗，问题是如果我的类名称已经足够简单了呢？加了_t会对用户代码的整洁性产生不必要的干扰。
　　风格3（Java风格）的问题：在c++中无法避免成员变量名称与参数名称冲突，java（或python）不存在这个问题是因为java中成员函数中引用成员变量时总是带个前缀this。但其实c++也可以这么干，只是出于习惯我们总是省略this前缀，这样的话就不存在什么问题了。
　　就我个人来说，目前倾向于采用java命名风格，原因是它最大程度地避免了命名冲突而又不会对代码带来太大的冲击，这或是就是为什么很多语言的命名风格会向它靠拢。