01、驼峰式

驼峰命名法（Camel Case）不同单词之间没有分隔符，采用大小写混合的方式区分不同单词。

1.小驼峰

如果第一个单词首字母小写，称为小驼峰（camelCase）。

2.大驼峰

如果第一个单词首字母大写，称为大驼峰（CamelCase）。

• 注意：大驼峰命名法还有一个名字，叫 Pascal 命名法。这是因为该命名规范最早由 Niklaus Wirth 在 1970 年代提出，以纪念法国数学家和物理学家 Blaise Pascal（1623年-1662年）。Pascal 是一位重要的数学家和自然科学家，对于概率论、流体力学和计算器的发明有重要贡献。

• 驼峰式是一种非常流行的将单词组合成单个概念的方式。在许多语言中（如 Java、JavaScript、C#），小驼峰常被用来命名局部变量和函数，大驼峰常用来命名全局变量和类。

02、蛇形式

蛇形命名法（Snake Case）使用下划线分隔不同单词。

1.小蛇式

如果所有单词都小写，称为小蛇式（snake_case）。

• 小蛇式通常用于声明数据库字段名。此外，URL 参数一般也使用 snake_case。在某些 API 设计中，如果要将参数值直接表示在 URL 中，可以使用 snake_case。例如 https://api.example.com/users?sort_order=desc

2.大蛇式

如果所有单词都大写，称为大蛇式（SCREAMING_SNAKE_CASE）。

之所以加个 screaming，因为在英文中，如果一个单词全部大写，表示大声喊叫，引起他人的注意。

大蛇式通常用于宏定义和被许多语言用来命名常量。

3.帕斯卡蛇形式

如果所有单词首字母都大写，称为帕斯卡蛇形式（Pascal_Snake_Case）。

• Pascal_Snake_Case 是将两种命名方式组合而成的一种命名风格。它是由 Pascal Case（帕斯卡命名法）和 Snake Case（蛇形命名法）组合而成。

• 这种命名方式在实际开发中较少使用，因为它将两种不同的命名风格结合在一起，可能会导致命名混乱，降低代码的可读性和一致性。

03、烤串式

烤串命名法（Kebab Case）使用中划线分隔不同单词。

烤串命名法使用中划线连接多个单词，从而形成一个字符串。由于这种连接方式形象地类似于烤肉串，因此取名为烤串命名法。

1.小烤串式

如果所有单词都小写，称之为小烤串式（kebab-case）。

• 小烤串式在 Lisp 编程语言中经常被用到，所以有时也叫做 lisp-case。

• URL 路径中经常使用小烤串式。例如 http://www.blog.com/cool-article-1。这是一种很好的、干净的、可读的单词组合方式。

• 我们在 K8S 的资源配置文件中也会看到 kebab-case。

此外，在 CSS 中，所有属性名称和大多数关键字值也主要采用 kebab-case 格式。

2.大烤串式

如果所有单词都大写，称之为大烤串式（SCREAMING-KEBAB-CASE）。

• 大烤串式主要用于突出强调被命名的对象，古老的 Cobol 编程语言中经常使用，所以有时也被称为 COBOL-CASE。

3.HTTP 头式

如果所有单词首字母都大写，称之为 HTTP 头式（HTTP-Header-Case）。

因为 HTTP 头部字段的命名使用这种方式，所以称之为 HTTP 头式，如 Content-Type、User-Agent 等。

04、匈牙利命名法

匈牙利命名法（Hungarian notation）是早期的规范，由微软程序员查尔斯-西蒙尼（Charles Simonyi）发明，因其为匈牙利人，故被称为匈牙利命名法。

• 匈牙利命名法要求标识符使用一个小写前缀来表示变量的类型或用途。按照在微软中的使用场景，分为匈牙利应用命名法和匈牙利系统命名法。

• 匈牙利应用命名法指在微软软件产品中使用的匈牙利命名法，比如 Word、Excel 和其他应用程序。

• 匈牙利系统命名法是指在 Windows 操作系统中使用的匈牙利命名法，因 Windows API 而被大家熟知。

  
  

• 匈牙利系统命名法在匈牙利应用命名法之后出现，二者的区别主要在于前缀的目的不同。

• 还有其他更多的前缀是根据微软自己的 MFC/句柄/控件/结构等东西定义的，就不过多描述了。

匈牙利应用命名法的前缀主要目的是力求对逻辑数据类型而非物理数据类型进行编码，也就是提示变量的目的是什么，或者它代表什么。

Simonyi 提出的大多数（但不是全部）前缀本质上是语义的，现在来看，一些前缀也表示物理数据类型，例如以 Null 做结尾的字符串使用 sz 前缀。然而，这些前缀仍然是语义上的，因为 Simonyi 的想法是使用语义化的前缀来表示变成语言的类型系统无法表达的逻辑上数据类型。

Simonyi 建议的大多数前缀都是自然语义的，但不是所有。下面几个是来自微软官方文档。

https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-6.0/aa260976(v=vs.60)
pX 指向另一个X类型的指针，这包含非常少的语义信息。
d 是一个前缀表示两个值的区别，例如，dY可能代表一个图形沿Y轴的距离，而一个仅仅叫做y的变量可能是一个绝对坐标。这完全是自然语义的。
sz 是一个无结束或零结束的字符串。在 C 中，这包含一些语义信息，因为C语言的char*类型的变量不确定是一个指向单个字符的指针，还是一个字符数组，或是一个零结束字符串。
w 标记一个变量是一个字。这基本上没有包含什么语义信息，因此可以被看作一种匈牙利系统命名法。
b 表示一个字节，和w对比可能有一些语义信息，因为C语言中，只有char型（以及signed/unsigned char)是一个字节长的，这些类型有时候被用来保存数值而非字符。这个前缀可以明确某个变量保存的是字符还是数值。
在使用匈牙利应用命名法的代码中有时候也可能包含匈牙利系统命名法，即在描述被单独以类型方式定义的变量时使用。

匈牙利命名法在 C++ 中被扩展而包含变量的作用域，由一个下划线隔开。

匈牙利命名法是一个十分复杂繁琐的命名规范，它诞生在 IDE 还不够发达的年代。在那个年代，当代码量很多的时候，想要确定一个变量的类型很麻烦，不像现在 IDE 都会给提示，所以才产生了匈牙利命名法，现在已经很少使用了。

常见命名规则以及适用场景

这里只介绍 3 种最常见的命名规范。

驼峰命名法（CamelCase）

驼峰命名法应该我们最常见的一个，这种命名方式使用大小写混合的格式来区别各个单词，并且单词之间不使用空格隔开或者连接字符连接的命名方式

大驼峰命名法（CamelCase）

• 类名需要使用大驼峰命名法（UpperCamelCase）

正例：ServiceDiscovery、ServiceInstance、LruCacheFactory
反例：serviceDiscovery、Serviceinstance、LRUCacheFactory

小驼峰命名法（lowerCamelCase）

• 方法名、参数名、成员变量、局部变量需要使用小驼峰命名法（lowerCamelCase）。

正例：getUserInfo()、createCustomThreadPool()、setNameFormat(String nameFormat)、Uservice userService;
反例：GetUserInfo()、CreateCustomThreadPool()、setNameFormat(String NameFormat)、Uservice user_service

蛇形命名法（snake_case）

• 测试方法名、常量、枚举名称需要使用蛇形命名法（snake_case）

• 在蛇形命名法中，各个单词之间通过下划线“_”连接，比如should_get_200_status_code_when_request_is_valid、CLIENT_CONNECT_SERVER_FAILURE。

蛇形命名法的优势是命名所需要的单词比较多的时候，比如我把上面的命名通过小驼峰命名法给大家看一下：“shouldGet200StatusCodoWhenRequestIsValid”。感觉如何？ 相比于使用蛇形命名法（snake_case）来说是不是不那么易读？

正例：

@Test
void should_get_200_status_code_when_request_is_valid() {
  ......
}

反例：

@Test
void shouldGet200StatusCodoWhenRequestIsValid() {
  ......
}

串式命名法（kebab-case）

• 在串式命名法中，各个单词之间通过下划线“-”连接，比如dubbo-registry。
  建议项目文件夹名称使用串式命名法（kebab-case），比如 dubbo 项目的各个模块的命名是下面这样的。

常见命名规范

Java 语言基本命名规范

1.类名需要使用大驼峰命名法（UpperCamelCase）风格。方法名、参数名、成员变量、局部变量需要使用小驼峰命名法（lowerCamelCase）。

2.测试方法名、常量、枚举名称需要使用蛇形命名法（snake_case） ，比如should_get_200_status_code_when_request_is_valid、CLIENT_CONNECT_SERVER_FAILURE。并且，测试方法名称要求全部小写，常量以及枚举名称需要全部大写。

3.项目文件夹名称使用串式命名法（kebab-case），比如dubbo-registry。

4.包名统一使用小写，尽量使用单个名词作为包名，各个单词通过 "." 分隔符连接，并且各个单词必须为单数。

正例： org.apache.dubbo.common.threadlocal
反例： org.apache.dubbo.common.threadLocal

5.抽象类命名使用 Abstract 开头。

//为远程传输部分抽象出来的一个抽象类（出处：Dubbo源码）
public abstract class AbstractClient extends AbstractEndpoint implements Client {

}

6.异常类命名使用 Exception 结尾。

//自定义的 NoSuchMethodException（出处：Dubbo源码）
public class NoSuchMethodException extends RuntimeException {
    private static final long serialVersionUID = -2725364246023268766L;

    public NoSuchMethodException() {
        super();
    }

    public NoSuchMethodException(String msg) {
        super(msg);
    }
}

7.测试类命名以它要测试的类的名称开始，以 Test 结尾。

//为 AnnotationUtils 类写的测试类（出处：Dubbo源码）
public class AnnotationUtilsTest {
  ......
}

POJO 类中布尔类型的变量，都不要加 is 前缀，否则部分框架解析会引起序列化错误。

如果模块、接口、类、方法使用了设计模式，在命名时需体现出具体模式。

命名易读性规范

1.为了能让命名更加易懂和易读，尽量不要缩写/简写单词，除非这些单词已经被公认可以被这样缩写/简写。比如 CustomThreadFactory 不可以被写成 ~~CustomTF 。

2.命名不像函数一样要尽量追求短，可读性强的名字优先于简短的名字，虽然可读性强的名字会比较长一点。 这个对应我们上面说的第 1 点。

3.避免无意义的命名，你起的每一个名字都要能表明意思。

正例：UserService userService; int userCount;

反例: UserService service int count

4.避免命名过长（50 个字符以内最好），过长的命名难以阅读并且丑陋。

5.不要使用拼音，更不要使用中文。 注意：像 alibaba 、wuhan、taobao 这种国际通用名词可以当做英文来看待。

正例：discount

反例：dazhe

Codelf:变量命名神器

这是一个由国人开发的网站，网上有很多人称其为变量命名神器， Guide 在实际使用了几天之后感觉没那么好用。小伙伴们可以自行体验一下，然后再给出自己的判断。

Codelf 提供了在线网站版本，网址：https://unbug.github.io/codelf/，具体使用情况如下：

我选择了 Java 编程语言，然后搜索了“序列化”这个关键词，然后它就返回了很多关于序列化的命名。