楚予微茫变量命名这个话题，我入行头几年一直没当回事。直到有一次，我接手一个Python统计脚本，里面有个变量叫p，定义它的老同事已经离职了。我翻了半小时代码，才猜出p大概是某个概率值——但也可能是price，甚至是page。那一刻我才明白，变量命名不是“新手课”，它是每天要重复几十次的决策，而每次决策的后果，都会在几个月后加倍返还给你。
这篇文章不是单纯列规则，而是想从“为什么”讲起，再落到不同语言、不同领域、不同排查场景里的具体做法。适合刚学编程的初学者、正在接手别人项目的开发者，还有需要给团队定规范的技术负责人。
1. 先搞清变量名的边界：合法性规则与可读性规则是两码事
很多人把“变量命名规则”当成一回事，但实际写代码的时候，它至少分两层：一层是编译器法律，一层是团队公约。这两层经常被混在一起讲，导致初学者以为只要是规范就都必须遵守，而老手又可能只盯着合法性，忽略了可读性。分开理解，后面所有细节才立得住。
1.1 编译器只在乎三条底线
第一层规则是语言标准强制的合法性规则，没有任何商量余地，写错一个字符，程序要么编译不过，要么运行时报语法错误。我总结下来，绝大多数编程语言都在三个层面做限制。
字符集限制是第一条。变量名能用的字符范围，每种语言有自己的定义。比如Java标识符只允许Unicode字母、下划线、美元符号以及数字，而Python 3比较宽容，Unicode字符都可以出现在标识符里，所以理论上你能写出中文变量名还能正常运行。C语言标准只保证ASCII范围内的字母、下划线和数字可用，如果需要跨平台兼容，最好不要在C/C++代码里用非ASCII字符命名变量。
第二条是起始字符限制。数字不能作为变量名开头，这条规则几乎所有语言一致。原因是词法分析阶段，编译器一看到以数字开头的字符流，会优先按数字常量解析，而不是当作标识符。所以 9lives 这种名字在任何主流语言里都是非法的，但 lives9 就没有问题。
第三条是保留字限制。变量名不能和语言关键字冲突，比如 if、for、while、class、int 这些词，在每种语言里都被编译器占用。你拿它们当变量名会直接报错，就算语言允许你用类似拼写，比如Java里用 Class 当变量名虽然合法，但几乎没有人会这么干，因为太容易和 class 这个概念混淆。
1.2 可读性规则才是决定变量价值的那一层
把“合法”和“好”分开，是理解变量命名的关键。合法的变量名可以叫 a、b、c、tmp、foo、x1x2x3，只要不违反上面三条硬性规则，编译器全部接受。但在真实项目里，这种名字大概率会成为维护期的痛点。
可读性规则没有语言标准强制，属于团队约定或行业惯例。常见的硬性可读要求包括：表意明确，变量名应该能让人推断出它的含义，比如 userList、orderCount、maxRetry，看到名字就能知道里面装的是什么；长度要适中，太短没有信息量，太长影响阅读，业界比较常见的做法是2到3个单词组合出一个名字，比如 customerId、requestTimeoutMs，如果超过5个单词，你该考虑的已经不是命名，而是这个类的职责是不是太重了；不要用无意义的缩写，idx 表示 index、cnt 表示 count 这类团队共知的缩写可以用，但到处造缩写就会让后来人看不懂。
还有两条很重要的词性和大小写惯例：布尔变量用 is、has、can 开头，比如 isDeleted、hasPermission、canRetry，普通数据变量用名词，函数方法名用动词开头；常量和普通变量的命名要区分，全大写的 UPPER_SNAKE_CASE 通常留给常量或宏定义，普通变量用对应语言的小写风格。这些规则没有编译器管着，靠的是团队规范和 code review，但恰恰是这类规则决定了项目后续维护成本。
1.3 两条规则冲突的时候，优先顺序是什么
我在实际操作里的原则是：先保证合法，再保证可读，最后才谈风格统一。举个真实案例，有些团队规定代码里不用缩写，但某个变量真的特别长，比如 flightDepartureAirportTimezoneOffsetSeconds，写出来接近40个字符。如果你们团队的风格指南允许在局部变量场景下用缩写，那么 tzOffsetSec 显然比超长命名更合适。
可读性规则的目的是降低理解成本，不是机械地“越长越好”。我在 review 代码时经常提醒成员，如果一个变量名需要用注释来解释，那就说明命名本身已经失败了，注释应该解释“为什么”，而不是解释“这个名字是什么意思”。这个优先顺序在后面的章节里会反复出现，所有细节最终都指向同一个原则：规则是为人服务的，不是反过来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 主流命名风格的适用场景与一致性成本
命名风格，本质上是对“拼接多个单词时怎么分隔、怎么处理大小写”的统一约定。不同风格的变量名写起来差别不大，但如果一个项目里混用两三种风格，维护成本会直线上升。这一节先把主流风格讲清楚，再聊聊风格不一致到底会付出什么代价。
2.1 四套主流风格和它们的变体
camelCase（驼峰式）是最常见的一种，首个单词全小写，后续单词首字母大写，比如 userName、createOrder。Java 和 JavaScript 的普通变量默认使用这种风格，极少有团队在这些语言里用 snake_case 写变量。
PascalCase（帕斯卡式）和驼峰式很像，区别在于第一个单词的首字母也大写，比如 UserName、CreateOrder。这套风格通常用于类名、接口名、结构体类型名，它表达的含义是“这是一个类型”，而不是“这是一个对象或实例”。
snake_case（蛇形式）全部小写，用下划线连接单词，比如 user_name、create_order。Python、Ruby、C 语言变量最常使用这种风格。很多从 Python 转 Java 的开发者会在这上面纠结一段时间，我从 Java 转 Python 的时候也经历过，老是下意识把 userName 写出来，然后被 linter 提示风格问题。
kebab-case（烤串式）全部小写，用短横线连接单词，比如 user-name。这套风格在大多数编程语言里不能用，因为短横线会被解析成减号运算符，所以它主要用于 CSS、HTML 属性名、URL 路径和配置文件。搜索引擎的关键词里经常出现 "css 控制伪元素变量"，CSS 自定义属性就大量使用 kebab-case，后面第4节会详细展开。
除了这四套，还有一个变体：UPPER_SNAKE_CASE，全部大写，下划线连接，用于常量、宏定义、环境变量名。比如 MAX_RETRY_COUNT、API_BASE_URL，这种命名方式传递的信息是“这个值在运行时不应该被修改”。
2.2 匈牙利命名法为什么被大量淘汰
这里要专门提一下匈牙利命名法。它是 Windows 编程时代的主流命名体系，核心思想是在变量名前加类型或作用域前缀，比如 strName 表示字符串，iCount 表示整型计数，pBuffer 表示指针缓冲区，g_nTotal 表示全局整型变量。
这套方法在 C 语言早年有一定价值，因为那时候 IDE 弱，变量类型要靠名字来记。但它带来两个问题：一是如果类型变了，变量名必须跟着改，否则就是纯粹的误导；二是现代 IDE 已经把类型信息放到悬浮提示和自动补全里，类型前缀从“帮助理解”变成了“冗余噪音”。
所以现在的团队规范里，很少再要求全局加类型前缀，即使要用，也只保留语义层面的前缀，比如 is、has、can 开头表示布尔值。如果看到有人还在代码里写 strUserName、iCount 这种名字，大概率是在维护十年前的老系统。
2.3 一致性带来的真实收益
我见过不少项目没有统一的命名风格，同一个代码库里既写了 user_name，又写了 userName，两边都合法、都可读，但混在一起，开发者做全局搜索的时候就得多试几次。这听起来是小问题，实际很消耗注意力和时间。
我在以前的团队里踩过这个坑。团队用 Python，但成员背景不同，从 Java 转过来的同事坚持用 camelCase，老 Python 程序员坚持用 snake_case。Code review 的时候，经常因为命名风格吵起来，review 的重点从逻辑正确性变成了个人偏好争论。后来我们把 snake_case 定为团队唯一变量风格，写进 README，并且让 linter 自动拦截非统一风格的代码。一个月后，搜索、替换、git 回滚这些日常操作的效率都有了肉眼可见的提升。
风格统一的收益，不是短期能直接看到的，而是让工具链和人脑的心智模型都更简单。你不需要在每次看到变量时多思考一步“这个项目用的是哪种风格”，注意力可以集中在真正的逻辑上。这就是一致性的价值。
3. 不同语言里，变量命名的硬规矩到底差在哪
这一节是很多初学者最需要的部分。不同语言的合法标识符规则、官方推荐风格、历史遗留习惯都不一样。我会挑最常见的几种语言展开，覆盖搜索引擎里热度最高的 Python、Java、C/C++、JavaScript、Bash 和 VBA 场景，并给出可执行的命名建议。
3.1 Python：下划线主导，PEP 8 说得明明白白
Python 3 的合法标识符由字母、数字、下划线组成，且不能以数字开头，同时还允许大量 Unicode 字符。这意味着中文变量名在 Python 3 里是合法的，可以正常运行。真实开发中，我建议在公共库、跨团队项目里还是用英文，但在内部脚本里，如果团队一致觉得中文更清晰，Python 3 是跑得通的。
PEP 8 对命名风格给了明确建议：普通变量和函数用 snake_case；类名用 PascalCase；常量用 UPPER_SNAKE_CASE；模块级私有变量加单下划线前缀 _var，表示“尽量不要在外部直接访问”；类内部的双下划线前缀 __var 会触发名称改写机制，用于避免子类命名冲突。
这套规则在实际中容易出问题的点是：单下划线 _var 只是约定，Python 解释器并不禁止外部访问，只有在 import * 时才排除它；而双下划线 __var 在类定义里会被改写成 _ClassName__var，新手很容易在这里突然遇到 AttributeError。至于双下划线前后都有、形如 __init__ 的名字，是 Python 内部方法的专用形式，普通变量千万不要去占用，否则会和框架机制冲突。
3.2 Java：标识符合法字符和驼峰式的统治地位
Java 的合法标识符规则由 JLS 规范约束：必须以 Unicode 字母、下划线、美元符开头，首个字符不能是数字，后续字符可以是字母、数字、下划线、美元符。纯粹从语言规范讲，$ 开头的变量名是合法的，但实际项目里没人这么写。原因是很多代码生成器、框架内部会用 $ 前缀生成临时变量，用来避免和用户变量冲突，你再去用 $ 开头，很容易踩进框架的命名空间。
Java 的行业编码规范基本是驼峰式一统天下：类名和接口名用 PascalCase，比如 UserService、OrderRepository；方法名用 camelCase，比如 getUserName、calculateTotalPrice；普通变量名用 camelCase，比如 userName、orderList；常量用 UPPER_SNAKE_CASE，比如 MAX_RETRY_COUNT、DEFAULT_TIMEOUT。私有变量和普通变量的命名规则一样，不需要额外加前缀，部分老团队会加 m 前缀表示 member（成员变量），但Java 主流的 Google Java Style 并不推荐这种写法。
Java 里还有一个高频痛点，搜索引擎热词里能看到 java: 找不到符号 符号: 变量 log 这种报错。很多情况下这个错误的根因就是变量名问题，比如拼写错误、作用域不对、大小写不一致。具体的排查链路我在第5节会详细拆解，这里先记住一个事实：Java 严格区分大小写，userName 和 username 是两个完全不同的变量。
3.3 C/C++：普通变量、指针、结构体、宏各有不成文的规矩
C 语言标准对合法标识符的规定更严格：只能由字母、数字、下划线组成，数字不能开头。但 C 语言里还有一条很多教材不会强调的规则：以下划线开头且后跟大写字母（如 _Xxx）或者包含双下划线（如 __xxx）的标识符，被保留给编译器和运行库使用，你自己的代码不应该去写。很多人没有这个概念，看到 Linux 内核代码里大量使用 __xxx，就模仿着命名自己的变量，这在某些编译环境下可能引发未定义行为。C/C++ 里的 __int128 就是一个典型例子，它是 GNU 编译器扩展提供的一个关键字，标准 C++ 里并没有这个类型。
C 语言业界的常规命名习惯是：普通变量用 snake_case，比如 int user_count；结构体类型名通常用 typedef 加 _t 后缀，比如 typedef struct user_info user_info_t，或者直接使用 PascalCase 风格；结构体变量一般用小写 snake_case，尽量和类型语义对应；指针变量的习惯有两种，一种在类型旁边加星号如 int* p_count，另一种在变量名前加 p 前缀如 pBuffer、pUser，只要团队统一，哪种都可以，但不要混用。
C++ 的 Google Style Guide 建议变量名用 snake_case，成员变量加下划线结尾，如 user_count_，这个下划线结尾的规则和普通局部变量区分开来，能快速判断一个变量的作用域。类名还是 PascalCase。如果你开发的项目没有明确规定，尽量沿用一个成型的风格指南，比自定义一套新规则要靠谱。
3.4 JavaScript：let、const 落地后的命名习惯
ES6 之后，JavaScript 变量声明从 var 变成 let 和 const，命名规则也更清晰了。默认优先使用 const，变量名用 camelCase；只有值会改变的时候才用 let；var 在团队规范里基本淘汰。
关于 var 和 let，有一个容易踩坑的点：var 声明的变量没有块级作用域，所以你在 for 循环里 var i，循环结束后 i 仍然存在；let 则有块级作用域。这个和命名规则关系不大，但会在排查“变量到底定义在哪”的时候让人怀疑人生。我在调试一个循环变量串值的 bug 时，最后发现是 var 声明导致的变量提升，先把 var 改成 let，问题立刻消失。
JavaScript 的标识符规则和 Java 接近，但有一个特殊点：$ 字符在 jQuery 时代经常被用作变量名前缀，比如 $btn、$container，表示这是一个用 jQuery 封装过的 DOM 对象。现在主流框架下这种写法不多见了，但如果你在维护老项目时看到，不要觉得奇怪。还有 _ 前缀，经常用来表示“私有属性”，虽然JavaScript 的私有属性在语言层面现在有 # 前缀语法，但 _ 前缀在很多代码库里仍然是约定俗成的习惯。
3.5 Bash 脚本：整数变量声明和变量名解析的坑
Bash 脚本的变量名合法规则很简单：只能包含字母、数字、下划线，且不能以数字开头。赋值时等号两边不能有空格，否则 Bash 会把左边当成命令名去执行。这是很多新手踩的第一个坑。
定义整数变量，通常直接写 num=10 就够了，因为 Bash 本身没有强类型。如果希望变量在算术表达式中被强制当作整数处理，可以用 declare -i num=10。在 Bash 里，declare -i 只影响算术表达式求值时的行为，并不能让变量像 C 语言里的 int 那样拥有固定范围。
环境变量的命名习惯，社区惯例是全大写加下划线，比如 MAX_RETRY_COUNT=3、API_BASE_URL="http://..."。普通脚本变量一般用小写或 snake_case。还有一个容易忽略的点：$1、$2、$?、$# 这些位置参数是保留的，不要在脚本里定义同名变量覆盖它们。如果拿 $? 当普通变量名使用，Bash 会执行特殊语义，运行结果会非常诡异。
3.6 VBA 和 Excel 宏里的变量声明与强制声明
VBA 的变量命名规则和大多数语言不太一样。首先，VBA 不区分大小写，user_count 和 User_Count 会被视为同一个变量。其次，VBA 默认允许未声明就使用变量，只要没有 Option Explicit 语句，拼错变量名不会报错，而是静默创建一个值为空的新变量。这种设计导致很多 Excel 宏出现诡异结果，根因其实是变量名拼写不一致。
搜索引擎热词里有一个典型问题：microsoft visual basic for applications报错编译错误:变量未定义。在绝大多数情况下，这是因为模块顶部加了 Option Explicit 强制声明，但代码里引用了未声明的变量名。解决这个问题就两个思路：在模块顶部补全 Dim 声明，或者逐个检查所有变量名的拼写。我的建议是，写 VBA 时永远保留 Option Explicit，虽然一开始会有一堆“变量未定义”报错跳出来，但它能让拼写问题在编译阶段暴露，比运行到一半出现诡异错误强得多。
4. 从指针变量到CSS自定义属性：特殊场景下的命名惯例
除了上面这些通用语言的规则，现实开发里还会遇到大量特殊变量类型。这一节我挑几个搜索引擎里热度较高的场景来展开：C/C++ 的指针变量和结构体变量、CSS 自定义属性变量、FreeSWITCH 通道变量、博图 PLC 变量、Maven 环境变量、存储过程变量，还有统计建模里的双变量与混杂变量。
4.1 结构体变量和指针变量：类型信息到底要不要写进名字里
C/C++ 里结构体变量和指针变量的命名，核心争议是“要不要把类型或指针信息带进变量名”。我见过三种主流做法。
第一种是类型前缀方式，pUser、pBuffer、pConnection 这种 p 前缀来自匈牙利命名法，优点是看到名字就知道它是“指针类型”。第二种是表意优先方式，user、buffer、connection，类型交给 IDE 提示。第三种是类型别名优先，如果用了 typedef int* int_ptr，再写 int_ptr p_data，是不是指针一目了然，也不需要额外花精力想前缀。
实践下来我的体会是：现代 IDE 里，指针信息在变量悬浮提示中处处可见，不必每次都写 p 前缀。但在一些代码库比较老、IDE 提示弱的场合，保留 p 前缀仍然实用，尤其是嵌入式领域。智能指针 shared_ptr<User> 普及以后，类型在别名中已经体现了指针语义，再在变量名里加 p 会显得啰嗦。
结构体变量的命名更简单，普通变量用类型的小写形式即可。比如：
c复制typedef struct {
char name[64];
int age;
} user_info;
user_info current_user;
user_info *p_user = ¤t_user;
这里的 current_user 比 u 或者 user_struct_abc 可读性强很多。命名结构体变量时，最重要的是让变量名的语义边界清楚，它表达的是“一个用户信息实例”，不是一个散装字段容器。我见过有人喜欢把结构体变量命名为 userInfoStruct，显得很啰嗦，直接 current_user 就够了，类型信息放注释里或者靠 IDE 展示更好。
4.2 CSS 自定义属性变量：双短横线前缀和 kebab-case
CSS 自定义属性，也叫 CSS 变量，命名规则和编程语言差别非常大。它的合法格式是必须以两根短横线开头，比如 --main-color、--font-size-lg。变量名区分大小写，--main-color 和 --Main-Color 是截然不同的两个变量。
因为 CSS 预处理器（Sass/SCSS、Less）也支持变量，很多人会把它们混淆。CSS 原生变量的核心特征是“参与级联”，它可以用在任意元素上，并从父级继承；Sass 变量则是编译时替换，不存在级联关系。命名风格上，社区主流用法是 kebab-case，因为 CSS 属性名本身就是 kebab-case，保持一致更容易读。
实际使用方式是这样的：
css复制:root {
--main-bg-color: #fff;
--button-radius: 4px;
}
.card {
background-color: var(--main-bg-color);
border-radius: var(--button-radius);
}
有人会用 --mainBgColor 这种 camelCase 写法，技术上没有问题，但在团队项目中我建议遵循 CSS 原生风格统一用 kebab-case。注意，CSS 变量的复用点在语义上要清楚，--spacing-unit 比 --s1 更容易维护，--color-primary 比 --blue 更能表达用途。
4.3 FreeSWITCH 通道变量：平台级变量名的约定俗成
FreeSWITCH 是电话交换领域的开源软交换系统，通道变量承载了通话中的大量状态信息，比如 caller_id_number、destination_number、hangup_cause、context、domain_name 等。这类变量名在 FreeSWITCH 官方文档、XML 配置、JavaScript 脚本、Lua 脚本里都会反复出现，命名风格统一为全小写加下划线。
这属于典型的“平台级变量”，名字由框架统一确定，你不能随意改成驼峰式。如果你在写模块时自定义通道变量，建议仍沿用全小写下划线的风格，与系统变量保持一致。更重要的是建立一张变量名对照表，把呼叫中心业务字段和通道变量一一对应，防止在多个模块之间引用同一个变量时出现大小写不一致导致的潜在问题。
4.4 博图PLC变量：工业自动化场景里的一大痛点
工业自动化项目里，我见过不少 PLC 程序的变量名是 DB1.DB_16、M0.0、Q0.1 这种由硬件地址生成的默认名。这类名字能直接看到地址，但语义完全缺失，维护的人根本不知道哪个点控制哪个阀门、哪个传感器。
西门子博图（TIA Portal）的工程实践中，比较成熟的命名组合是“块名加数据类型加用途”。比如电机启动命令写 Motor_Start_Cmd，阀门反馈写 Valve_Feedback，模拟量原始值写 AI_Raw_Value，水泵频率设定写 Pump_Freq_Setpoint。这种命名虽然长，但在 PLC 世界里，语义清晰比长度重要得多。
实际项目里，很多工程师为了方便走线，在 PLC 端维护一组短的物理地址，同时在符号表里写清楚 Symbol Name 和注释。这样做的好处是，画电气图的人、写 PLC 程序的人、做上位机报表的人都能各取所需。符号名、注释、硬件地址三者一一对应，程序可维护性自然就上去了。
4.5 Maven 用户变量和环境变量：大小写与历史遗留问题
Maven 是 Java 生态的构建工具，在 Windows 上配置 Maven 经常要添加 MAVEN_HOME 或 M2_HOME 环境变量。很多新手看到网上的教程里两种写法并存，就以为必须都配，其实只需要让 Maven 的 bin 目录加入 PATH，并且 MAVEN_HOME/M2_HOME 指向同一个安装路径即可。
环境变量的命名规则相对宽松，但也容易踩坑。Windows 环境变量不区分大小写，可如果你把同一个变量在用户变量和系统变量里分别配置了不同的值，其结果就是用户变量覆盖系统变量，容易造成版本冲突。另外，变量名里不要加空格和特殊符号，尽量避免路径中的中文，虽然 Windows 能处理，但一些基于 cmd 或 PowerShell 的脚本工具可能会出现乱码。
我在搜索引擎热词里还看到了“win11 maven 配置到用户变量”的说法，这就是个典型场景。配置到用户变量还是系统变量，差别在于影响范围：用户变量只对当前用户生效，系统变量对所有用户生效。个人开发机配用户变量就够了，不必给机器上所有账号改配置。
还有一个容易让人困惑的概念：变量树。在乐吾乐这类组态软件或可视化平台里，变量树本质是一种图结构数据，变量树的节点名会和组态页面的控件绑定。命名时我建议使用“系统_区域_设备_属性”的分层结构，例如 SYS_A_Pump_Status，比随手写 Voltage 或 temp1 更好维护，也方便做跨页面联动。
4.6 存储过程和系统开发里的变量命名规则
数据库存储过程的变量命名规则和通用编程语言类似，但有一些数据库特有的坑需要提防。以 MySQL 为例，变量分三类：系统变量以 @@global. 或 @@session. 开头，由数据库引擎提供；用户变量用单个 @ 开头，比如 @user_name；局部变量用 DECLARE 关键字声明，只能在存储过程或函数内部使用。
存储过程里常用的命名约定是给局部变量加前缀或后缀，比如 v_user_name、p_order_id 或 user_id_out。加 v 前缀的主要原因是避免和列名冲突。如果你在存储过程里写：
sql复制DECLARE user_name VARCHAR(64);
SELECT user_name FROM users WHERE id = 1;
MySQL 在某些情况下会把 user_name 解析为列名而不是变量名，产生歧义错误或返回错误结果。我给所有局部变量加 v_ 前缀之后，这类问题基本没再出现。存储过程命名规则里，区分“列名”和“变量名”是最重要的一条。
4.7 统计建模里的变量命名：双变量、混杂变量的可解释性
搜索引擎热词里有“双变量空间自相关”和“混杂变量”，这两个词属于统计建模领域。数学统计意义上的“变量”，命名规则和编程语言不同，它更强调可解释性。
双变量空间自相关，通常用 LISA 统计量或 Moran 散点图分析两个地理要素之间的空间关系。变量命名必须体现空间尺度、时序两个维度，比如 `income_2023_spatial