适合小驼峰命名有哪些,为什么很多人不建议使用驼峰命名法,有什么弊端么?

发布时间:

适合小驼峰命名有哪些

适合小驼峰命名有哪些

为什么很多人不建议使用驼峰命名法,有什么弊端么?

因为可能编撰者本人并不喜欢驼峰命名。

有些事情已经形成了较大范围的行业习惯了。类的命名使用大驼峰,方法和变量的命名使用小驼峰,常量全大写,并且使用下划线来分割单词。

但是重要的是整个团队要保持统一的风格,否则可能造成工作效率的低下。

试想如果有人用大驼峰去命名一个变量或方法,其他人可能会误以为那是一个直接来自类的调用的静态方法;

或是当你看到了一个全大写并且用下划线来分割的常量,你以惯性思维以为它是个常量,但实际上你的同事把它定义为一个变量,而他没有遵守大家约定的规范,那么你所调用到它的地方,可能它的值随时会发生变化,对你造成不必要的麻烦。

如果不巧的是,你所在的团队所习惯的规范与你自己的习惯有所矛盾,那要么你有足够的力量去改变所有其他人的习惯,要么就赶快改变自己的习惯,来适应团队。否则等待你的可能就是一句“你特么傻X啊搞这种命名?!”

什么是驼峰命名法?

驼峰的问题在于歧义和繁琐。大小写的切换会降低输入速度,比较繁琐,连续的字母在英文中会产生歧义,比较典型的比如to_ld和Told。其实哪个命名法都不是完善的,匈牙利命名法更啰嗦。现在比较推崇的是使用下划线,这个命名长度更长,但方便输入而且很少有歧义。个人理解,在哪个环境下,跟随使用哪种命名法是最合理的,比如用微软环境,那么就用类匈牙利命名法,和系统内置保持一致,用java,那么就是小写 下划线,这样整体程序和内置函数命名保持一致是最合理的。