为什么很多人不建议使用驼峰命名法，有什么弊端么？
最近在看CI Framework 官方文档认为不应使用驼峰命名法。
因为正统的软件工程里面，命名法都是组合使用的，举个简单的例子

            @Service // 注解、类型用大驼峰    class MyAppController implements IAppController {       @Resource       private MyAppService myAppService; // 成员变量用小驼峰           /**        * 获取用户信息，Service会封装urlencoded格式，即user_id=??&user_name=??        * @return {{ user_id: String, user_name: String }}; // 数据库/JSON Key使用小蛇         */       @Override       public String getUserInfo() { // 成员函数用小驼峰           String userInfo = myAppService.getUserInfo();           StringBuffer buffer = new StringBuffer();           buffer             .append(MY_APP_USER_HEADER) // 全局常量用大蛇             .append(userInfo);           return buffer.toString();       }    }

所以哪儿有什么不建议使用的

软件上的命名法都是组合使用，在什么场景用什么方式来保证代码的可阅读性，一眼看过去就知道写的是什么。