命名规则 (程序设计)
命名规则（naming convention）是電腦程序設計的源代码针对標識符的名称字符串进行定义（即「命名」）而规定的一系列规则。通常是为了提高源代码的易读性、易认性、程序效率以及可维护性。命名规则根据各个程序语言的规格、内存大小等硬件制约、编辑器以及集成开发环境的功能等等会有各种制约。
命名规则的选择（及其执行的程度）通常是一个有争议的问题，不同派系的人会觉得自己的观点最好而其他人则是次等的。 而且，即使采用了已知且定义明确的命名规则，某些组织也可能无法始终如一地遵守这些规则，从而导致不一致和混乱。 如果命名规则在内部不一致、任意、难记，或者以其他方式显得负担大于好处，则命名规则会遇到更多的挑战。 精细挑选的标识符可以让开发者和分析器更容易理解系统在做什么，或者如何修改或将源代码扩展运用到新需求上。 比如这句声明
在语义上是正确的，但是其目的却不明显。而相比较之下，写成
则提示了源代码的意图和含义，至少对了解上下文的人来说更清晰。
最基本的規則中包括對識別碼長度的規定。在某些情況下，上限是通過提供數值來設置的，而另一些情況下則使用了啟發式的方法或準則。
識別碼長度的規則是有爭議的，適當的長度應視具體情況而定。
要考慮的要點包括：
一些早期的鏈接器將變量名限制為6個字符或更少，以減少內存使用，這也是早期的程序會限制識別碼長度的原因之一。
一些命名规则对大小写和数字的使用加以限制，比如只能用小写字母，或者只能用大写字母。有些场合虽然可以保留大小写，但功能上并不赋予区别。 通常推荐使用「有实际含义的标识符」。如果单个单词无法表述清晰则可以使用多个单词，因此命名规则需要规定多个单词如何连接。这样还可以避免与各个程序语言使用的保留字冲突的问题。大多数语言的标识符不允许空格，而不加空格又会导致难以阅读，因此需要制定空格的替代方式。 在字母数字的单词里使用制定的区分字符进行连接，常用有 连字符 ("-") 、下划线 ("_")，比如两个单词的 "codice_1" 可写成 "codice_2" 或者 "codice_3"。连字符非常常用，包括 COBOL (1959), Forth (1970)以及 Lisp (1958)，而在 Unix 命令和包里也很常见。在 CSS 中也是如此。 这种做法没有一个通称，有人叫 "lisp-case" 或者 "COBOL-CASE" （是为了与 "Pascal case" 相区别），或者叫 "kebab-case"、"brochette-case"等等。 但至少是从 2012 年之后,  "kebab-case" 这个叫法越来越流行。
与此相比，在 FORTRAN/ALGOL 语言的传统中，特别是 C语言 和 Pascal语言 家族，曾使用连接号用于 中缀表示法 的减法运算符，而且也不希望前后加空格, 因此就无法用此方法来命名标识符。而用下划线连接小写字母的方法则在 C 家族（包括 Python）里都很常见，比如 "The C Programming Language" (1978) 即可见到，通称为 snake case. 而像 UPPER_CASE 这样用下划线连接大写字母的做法则常见于 C预处理器 里的宏，所以被称为 MACRO_CASE；以及 Unix 中的 环境变量，比如 bash 里的BASH_VERSION。有时会被幽默地称作 SCREAMING_SNAKE_CASE。
另一种做法就是在单词组合成一个字符串的中间使用大写字母，被称作駝峰式大小寫"（camelCase）或者 "Pascal case"等等，也就把 "codice_1" 写成 "codice_5" 或者 "codice_6"。这种方式常见于 Pascal、Java, C#以及Visual Basic。而对于首字母缩写词的处理方式仍会不一样。（比如 codice_7 中的 "XML" 和 "HTTP），有些会用小写以易于打字和阅读（比如 codice_8）而有些会保持大写以保证准确性（如写成codice_9）。
有一些命名规则不仅是特定程序、某个特定项目和问题的规则和需求，还通过软件架构称为对其下层的程序语言和跨项目的一个方法论框架。 最著名的命名规则包括匈牙利命名法，具体包括“系统匈牙利命名法”和“匈牙利应用命名法”。比如变量 szName 中的前缀 "sz" 代表其是一个零结束字符串。
原则上使用小写字母。在C标准库里，最常用的做法是使用缩写名称，如用于测试是字符是否为字母数字的函数写成 codice_10 ，而C++的标准库了则常用下划线作为单词分隔符（如 codice_11）。而C预处理的标识符则只用大写字母和下划线（因为很多程序语言都用全大写标示常量），带两个下划线或者以下划线和一个大写字母打头的名字都预留给编译器，因此都不能用（比如 codice_12 或者 codice_13）。 虽然这表面上与 类似，但语义上完全不同，因为下划线是标识符的值的一部分，而不是 stropping 那样只是表示引用： codice_14 的值是 codice_14 （被预留），而不是 codice_16（但是在一个不同的命名空间）。
C# 命名规则基本上遵循微软的 .NET 语言的规范。 （详见后续 .NET 章节），但 C# 编译器并不强制使用命名规则。微软推荐仅用 codice_17 和 camelCase，后者仅用于方法参数和本地方法变量名（包括本地方法 codice_18 值）。一个不适用 PascalCase 的特例，是标识符开头的双字母首字母缩写词，这时两个字母都要大写，如 codice_19，但这不适用于更长的首字母缩写词里，如 codice_20。该规范还推荐 codice_21 的名字要用 codice_17 并在开头加一个大写字母 codice_23，如 codice_24。
微软规范对 filed 命名仅限于 codice_25, codice_26 和 codice_27，并明确指出如果非静态、或者有其他可接入层级（比如 codice_28 和 codice_29）则不在规范范围之内。 最常用的做法是所有 filed 都使用 PascalCase ，而只有 codice_29 （且  codice_18 或 codice_25），这些例外使用 camelCase 并添加一个下划线，如 codice_33。
标识符可以添加 @ 符号却不改变含义。也就是说  codice_34 和 codice_35 均指同一个对象。在规则上，这一前缀仅用于当该标识符是预留关键词（比如 codice_36 和 codice_37，不加前缀就不能当成标识符），或者是有上下文关键词（比如 codice_38 和 codice_39，并不严格要求有前缀，至少不是所有声明都要求，比如尽管 codice_40 声明有效，但这会被看作 codice_41 以让读者立即知道后者是一个变量名）。 Java的命名规则是由多个社区制定的，包括昇陽電腦、网景、AmbySoft 等等。下述采用昇陽電腦制定规则的例子， 比如 "CamelCase"，不用空格直接连起来，每个单词首字母大写，比如 "CamelCase".
缩写词长达三个字母及其以上时用 CamelCase 而不是全大写（比如 codice_42 不写作codice_43），这个规则可以适用至两个字母词 (如 codice_44). JavaScript 的内置库采用与 Java 同样的命名规则。数据类型和建造函数使用 upper camel case (RegExp, TypeError, XMLHttpRequest, DOMObject) 而方法使用 lower camel case (getElementById, getElementsByTagNameNS, createCDATASection)。为了保持统一，大部分 JavaScript 开发者都遵循此命名规则。 微软公司 Microsoft .NET 推荐大部分标识符都用 codice_45（而参数和变量推荐用 lowerCamelCase) 这是所有 .NET 语言的通则， 微软还推荐无需使用（匈牙利命名法那样的）前缀提示， 而是推荐在后面加上基础类名，如写成 codice_46 而不是 codice_47。 Objective-C 使用源于 Smalltalk 的代码方式。通用的变量、函数的顶层条目，包括类、协议都用 UpperCamelCase 并用一个短的全大写前缀标示命名空间，比如 codice_48, codice_49, codice_50 以及 codice_51。常量可以有小写字母k打头的前缀如 codice_52。 即时对象的变量使用带下划线的 lowerCamelCase，如 codice_53 and codice_54。Method 名使用多个 lowerCamelCase 并用冒号区分如 codice_55, codice_56 and codice_57. Perl 继承了C中的一些规则。本地范围内的变量和子程序名用小写字母加下划线。包变量采用 title case，声明的常量全大写。包的名字采用 camel case 但 pragmata 例外，比如 codice_58 和 codice_59用小写。
PHP 推荐方式写在 PSR-1 (PHP Standard Recommendation 1) 和 PSR-12 中。 根据 PSR-1，类的名字要用 PascalCase, 类的常数要用 MACRO_CASE，而 method 名要用 camelCase。
Python和Ruby都推荐类名使用 codice_45，常数名使用 codice_61，其他名字用 codice_62。 Swift語言的命名规则根据不同发布有所变化。但是随着 Swift 3.0 的重大更新后，其命名规则规范更为清晰，希望能对所有第三方的 API 命名和声明规则进行标准化。变量、函数声明的命名规则还是以 codice_63 为基础。常数通常使用 enum 类型定义。类和其他类型的声明采用 codice_45。