1、骆驼式命名法（Camel-Case）又称驼峰式命名法，是电脑程式编写时的一套命名规则（惯例）。正如它的名称CamelCase所表示的那样，是指混合使用大小写字母来构成变量和函数的名字。程序员们为了自己的代码能更容易的在同行之间交流，所以多采取统一的可读性比较好的命名方式。
2、骆驼式命名法就是当变量名或函数名是由一个或多个单词连结在一起，而构成的唯一识别字时，第一个单词以小写字母开始；从第二个单词开始以后的每个单词的首字母都采用大写字母，例如：myFirstName、myLastName，这样的变量名看上去就像骆驼峰一样此起彼伏，故得名。
驼峰命名（camel）
首字母小写，第二个单词字母大写； JavaScript中，变量、函数名使用驼峰命名
帕斯卡命名（pascal）
每个单词的首字母大写， JavaScript中，类型是帕斯卡命名
短横线命名（kebab-case）
匈牙利命名
基本原则：变量名=属性+类型+对象描述
匈牙利命名法关键是：标识符的名字以一个或者多个小写字母开头作为前缀；前缀之后的是首字母大写的一个单词或多个单词组合，该单词要指明变量的用途。
匈牙利命名法通过在变量名前面加上相应的小写字母的符号标识作为前缀，标识出变量的作用域，类型等。这些符号可以多个同时使用，顺序是先m_（成员变量），再指针，再简单数据类型，再其他。
例如：m_lpszStr, 表示指向一个以0字符结尾的字符串的长指针成员变量。
匈牙利命名法中常用的小写字母的前缀：
变量名由a-z,A-Z,0-9,_（大小写字母，数字，下划线）组成，并且开头不能为0-9（数字）
变量命名方面流行的有以下几种：
一、匈牙利命名法
这种命名法的出发点是把变量名按：属性+类型+对象描述的顺序组合起来，以使程序员作变量时对变量的类型和其它属性有直观的了解，下面是HN变量命名规范。
属性部分：
g_ 全局变量
c_ 常量
m_ c++类成员变量
s_ 静态变量
类型部分：
数组 a
指针 p
函数 fn
无效 v
句柄 h
长整型 l
布尔 b
浮点型（有时也指文件） f
双字 dw
字符串 sz
短整型 n
双精度浮点 d
计数 c（通常用cnt）
字符 ch（通常用c）
整型 i（通常用n）
字节 by
字 w
实型 r
无符号 u
描述部分：
最大 Max
最小 Min
初始化 Init
临时变量 T（或Temp）
源对象 Src
目的对象 Dest
举例：
hwnd ： h 是类型描述，表示句柄， wnd 是变量对象描述，表示窗口，所以 hwnd 表示窗口句柄；
pfnEatApple ： pfn 是类型描述，表示指向函数的指针， EatApple 是变量对象描述，所以它表示指向 EatApple 函数的函数指针变量。
g_cch ： g_ 是属性描述，表示全局变量，c 和 ch 分别是计数类型和字符类型，一起表示变量类型，这里忽略了对象描述，所以它表示一个对字符进行计数的全局变量。
上面就是HN命名法的一般规则。
二、驼峰命名法
驼峰命名法的中心点在于每个单词的开头大写，而驼峰命名法又可分为大驼峰和小驼峰，大驼峰表示所有单词开头都大写，小驼峰表示第一个单词开头小写，后面的单词开头大写
大驼峰：EatSimpleApple
小驼峰：eatSimpleApple
一般大驼峰用于函数命名，小驼峰用于变量命名
当出现缩写（如IP）时，如果缩写在开头，则若为大驼峰则全部大写，小驼峰则全部小写，若不在开头，则全部大写
大驼峰：IPAddIP
小驼峰：ipAddIP
不过也有将缩写看作一般单词的写法：
大驼峰：IpAddIp
小驼峰：ipAddIp
三、帕斯卡命名法
帕斯卡命名法是指每个单词之间用下划线隔开，每个单词都小写（缩写也一样）
示例：eat_simple_apple
示例：ip_add_ip
1、小驼峰式命名法（lower camel case）：
第一个单字以小写字母开始，第二个单字的首字母大写。例如：firstName、lastName。
2、大驼峰式命名法（upper camel case）：
每一个单字的首字母都采用大写字母，例如：FirstName、LastName、CamelCase，也被称为 Pascal 命名法。
变种：StudlyCaps，是“驼峰式大小写”的变种。
补充说明，在JAVA中：类名的标识符一般用大驼峰式书写格式，方法和变量的标识符则多用小驼峰式书写格式。
使用驼峰命名法(Camel Casting)的时候总是会为缩写，常用语该怎么表示产生困惑，网上搜索了一下，发现一篇 文章 。由于文章是需要medium 订阅的，因此我连翻译带补充了一下。
每种语言都有自己的命名习惯，尤其在遇到缩写的情况，例如: JSON orJson, URL or Url, HTTP or Http。在使用 Camel Casting 的时候怎么命名一直没有一致的标准。
一种“简单”的回答是: 遵循你所使用的语言的规范或框架的规范。这种回答其实还是没有标准。而上述情况是如此常见，因此无论如何我们总需要把“共识”再推进一步。
下面列出了一个将英语短语转变为 camelCase 的思路。
其中有个特例， iOS 还是 IOS ？考虑到已经有了一些常用的用法，例如在 ReactNative 中的 ActionSheetIOS 或者 LinkingIOS 之类，所以建议用 IOS 而不是 iOS ，因此， supportsIpv6OnIos - supportsIpv6OnIOS 。
驼峰的问题在于歧义和繁琐。大小写的切换会降低输入速度，比较繁琐，连续的字母在英文中会产生歧义，比较典型的比如to_ld和Told。
其实哪个命名法都不是完善的，匈牙利命名法更啰嗦。
现在比较推崇的是使用下划线，这个命名长度更长，但方便输入而且很少有歧义。
个人理解，在哪个环境下，跟随使用哪种命名法是最合理的，比如用微软环境，那么就用类匈牙利命名法，和系统内置保持一致，用java，那么就是小写+下划线，这样整体程序和内置函数命名保持一致是最合理的。
本文转载自互联网，如有侵权，联系删除
