本文旨在讨论常用的命名方式，以及如何写出规范的名字。希望可以通过讨论，让命名变的越来越规范，通用，易于交流。
命名风格
常用的函数，变量，API命名
对于命名函数，变量，api接口通常有两种比较通行的命名风格：Camel Case, Underscore.
Camel Case(大小写交叉)
Camel Case是指采用大小写区分不同的单词联接。
它通常可以分成几种不同的子类型：
1、首字母大写，例如： AnEmptyFunction
2、首字母小写，例如： anEmptyVariable
3、首字母下划线，后面接CamelCase。
比如 _aCamelCaseVariable， _ACamelCaseFunction
4、将压缩单词成一个字母，例如：mCount(Member Count)， mbSend(Member Button Send)
Underscore(下划线)
Underscore是指采用下划线"_"区分不同的单词联接，然后单词采用统一的大写或者小写格式。
他通常可以分成几种不同的子类型：
1、大写，例如： _AN_EMPTY_FUNCTION, AN_EMPTY_FUNCTION
2、小写，例如： _an_empty_function, an_empty_function
3、多个下划线，通常用于定义特殊功能的变量，例如: __FILE__
下划线的特殊性
对于一些对成员变量访问权限范围没有限定的语言，我们通常会添加下划线来表达成员是私有的。
一些常见的不好的设计
在命名时，通常会发现一些不良的设计。
在URL上区分大小写
比如 设计出来的API是这样的：/User/Profile
推荐：所有URL地址采用小写。
两个单词没有区别的连接起来
比如errmsg, errcode
使用两个或者两个以上的下划线
比如 err\_\_\_msg
在同一个变量是混用不同的风格
比如：_A_very_Bad_STYLE_
采用拼音或者中英文混编
比如： lao_si_ji_driving, hanzi(汉字还是汉子？)
由于错误的方式有很多种，这里就不再一一例举了。
小结
命名的主要作用是交流与沟通，也是让自己能更容易看懂的技能，写出好的命名是非常有价值的。
通常不同的企业或者团队会有不同的规范，而规范通常是基于一定的规则的。通常大部分的命名规范都是基于以上讨论的命名规则的。
所以了解这些基本的规则，可以更好的理解，并适应不同的团队的具体规范。
以上是简单的关于命名的一些讨论，欢迎一起讨论，总结，让我们的开发更加的容易。