三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

编程命名规则详解：驼峰、帕斯卡、蛇形与烤串命名法

发布时间：2026/8/14 7:23:33 三亩地 编程学习日记
编程命名规则详解：驼峰、帕斯卡、蛇形与烤串命名法

1. 命名规则：从混乱到秩序的基石

干了这么多年开发，我见过太多因为命名问题引发的“血案”。一个变量叫a，另一个叫tmp，三个月后连自己都看不懂当初写的什么鬼；团队协作时，你写的getUserName，他写的fetch_user_name，我写的QueryUserName，光是统一风格就能开半天会。命名，这件看似微不足道的小事，其实是代码可读性、可维护性和团队协作效率的基石。它就像建筑行业的图纸标注，如果每个人用的符号和缩写都不一样，这楼迟早要盖歪。

今天我们不聊那些高深的设计模式或算法，就扎扎实实地把编程中最基础、也最容易被忽视的四种命名规则掰开揉碎了讲清楚：驼峰命名法、帕斯卡命名法、蛇形命名法和烤串命名法。别小看它们，无论是你写Java、Python，还是配置STM32的寄存器、在Altium Designer里进行ad20蛇形走线，甚至是理解三星DDR命名规则，都绕不开这些基本的命名约定。掌握它们，不仅能让你写出更专业的代码，更能让你读懂别人的代码和文档，是程序员从“能跑就行”到“优雅工程”的必经之路。

2. 四大命名法深度解析与选用指南

命名法的核心，其实是在解决一个矛盾：计算机喜欢简短无歧义的标识符（比如a1,var2），而人类需要能表达语义、易于阅读和记忆的短语（比如“用户的名字”）。于是，各种命名法应运而生，它们本质上都是将人类语言中的词组，转换成符合编程语言语法限制（通常不能有空格，区分大小写）的连续字符串的规则。

2.1 驼峰命名法

驼峰命名法可能是最常见的一种，它的特点是除第一个单词外，后续每个单词的首字母大写，整体看起来像骆驼的峰背，因此得名。它主要应用于变量、函数（方法）名等。

核心格式：userName,calculateTotalPrice,isValidFlag

典型应用场景：

  1. Java、JavaScript、Go等语言的变量、方法（函数）名：这是驼峰式的主战场。例如在Java中，一个获取用户信息的方法通常会命名为getUserInfo()。
  2. 数据库字段名（部分约定）：虽然数据库通常对大小写不敏感，但为了在代码中映射时保持一致，许多团队会使用驼峰式命名字段，如userId，createdAt。
  3. JSON属性名：在前后端交互的JSON数据中，属性名普遍采用驼峰式，如{"userName": "张三", "orderId": 123456}。

为什么选择驼峰式？它的优势在于平衡了可读性和输入的便捷性。单词之间没有分隔符，输入流畅；通过大小写变化自然分割单词，阅读时虽然需要一点“断词”的脑力，但对于习惯了的开发者来说非常自然。它避免了使用下划线（需要按Shift+减号），在键盘输入上更高效。

注意：在强调**java 标识符命名规则时，必须明确，Java语言规范强制要求方法名、变量名采用小写开头的驼峰式**。这是语言层面的约定，不容违反。类名和接口名则采用帕斯卡命名法（见下文）。

实操心得：在团队中推行驼峰命名时，最容易出的问题是缩写。比如“用户ID”，是写成userId还是userID？我个人的习惯是，除非是像ID、URL、HTTP这种全球通行的、全大写的缩写，否则将缩写视为一个普通单词，只大写首字母。即userId（推荐）优于userID。因为ID在变量名中间全大写，会破坏驼峰“波浪形”的视觉节奏，显得突兀。团队内必须对常见缩写有一份统一约定。

2.2 帕斯卡命名法

帕斯卡命名法，也叫大驼峰命名法或帕斯卡拼写法。它与驼峰命名法的唯一区别就是：第一个单词的首字母也要大写。

核心格式：UserName,CalculateTotalPrice,HttpResponse

典型应用场景：

  1. 类名、接口名、结构体名、类型名：这是帕斯卡命名法最经典的应用。在Java、C#、TypeScript等语言中，当你看到UserController、OrderService这样的标识符，几乎可以立刻断定它是一个类或接口。这为代码阅读提供了极强的语义提示。
  2. 枚举类型及其值（在某些语言中）：例如在C#中，枚举类型Color和它的值Red、Blue都常用帕斯卡式。
  3. 公共API或库的导出名：在构建供他人使用的库时，公开的类、函数名使用帕斯卡式显得更加正式和清晰。

与驼峰式的分工： 你可以这样简单记忆：“类用帕斯卡，对象（实例）和动作（方法）用驼峰”。User是一个类（帕斯卡），user是这个类的一个实例对象（驼峰），user.getName()是调用该对象的一个方法（驼峰）。这种命名上的差异，让你在浏览代码时，无需查看声明就能对标识符的种类有个初步判断，极大提升了代码的可读性。

案例分析：STM32命名规则意法半导体的STM32系列微控制器型号，虽然不是严格的编程标识符，但其命名规则也暗含了帕斯卡式的逻辑。例如STM32F407VET6：

  • STM32：系列名，可视为“命名空间”。
  • F4：子系列，大写字母开头。
  • 07：特定型号。
  • V：引脚数（100脚）。
  • E：Flash容量（512KB）。
  • T6：封装和工作温度。 虽然包含数字，但其核心部分（F、V、E）都是用大写字母来标示不同维度的特征，这种用大写字母分割不同信息段的方式，与帕斯卡命名法用大写字母分割单词的思想同源，都是为了清晰传达结构化信息。

2.3 蛇形命名法

蛇形命名法使用下划线_来连接所有单词，并且所有字母通常为小写。它看起来像一条蛇，因此得名。

核心格式：user_name,calculate_total_price,is_valid_flag

典型应用场景：

  1. Python、Ruby、PHP等语言的变量、函数名：在Python社区，PEP 8风格指南明确推荐使用蛇形命名法（小写+下划线）来命名函数、方法和变量。这已经成为Python世界的铁律，如def get_user_info():。
  2. 数据库表名和字段名：在SQL语言和许多数据库系统中，表名和字段名广泛使用蛇形命名，如user_account、order_detail。这是因为SQL标准对大小写不敏感（取决于配置），使用下划线能确保在任何环境下都能明确分隔单词。
  3. 文件命名：在操作系统层面，尤其是类Unix系统，文件名常用蛇形命名，因为它兼容性最好，如config_server.py。
  4. 环境变量：系统环境变量几乎全部采用大写蛇形命名，如JAVA_HOME、PATH。
  5. 常量：在许多语言中，常量（值不可变）会采用全大写的蛇形命名法，如MAX_CONNECTIONS = 100，这使其在代码中非常醒目。

为什么选择蛇形？蛇形命名法的最大优势是极高的清晰度。下划线是一个显式的、无歧义的分隔符。在视觉上，单词的边界一目了然，特别是在字体较小或快速浏览时，比依赖大小写变化来分词更加可靠。对于新手来说，也更容易理解和遵循。

避坑技巧：在Python中，蛇形命名法也用于类方法名。但要注意，__double_underscore__（双下划线开头和结尾）在Python中有特殊含义，是“魔术方法”或系统定义名称，如__init__。而_single_leading_underscore（单下划线开头）通常暗示该属性或方法是“内部使用”的，是一种弱私有化约定。不要随意使用前导下划线。

2.4 烤串命名法

烤串命名法，也叫脊柱命名法或短横线命名法，使用连字符-来连接所有单词，且所有字母通常为小写。它看起来像一根竹签穿起的烤肉串。

核心格式：user-name,calculate-total-price,is-valid-flag

典型应用场景：

  1. HTML属性、CSS类名和ID：这是烤串命名法的绝对统治区。在HTML中，>问题现象可能原因解决方案与建议代码检查工具报错“命名不规范”1. 使用了错误的命名法（如在Python中用驼峰命名变量）。
    2. 大小写错误（如userid应为userId或user_id）。
    3. 使用了非法字符（如空格、连字符）。1. 对照项目规范，确认该标识符应使用的命名法。
    2. 仔细检查单词边界。使用IDE的重命名重构功能安全修改。
    3. 牢记：编程标识符中只能使用字母、数字、下划线（有时美元符号$），且不能以数字开头。团队中命名风格不统一1. 缺乏明确的书面规范。
    2. 有规范但未工具化，靠自觉。
    3. 新成员未经过培训。1. 立即制定并公布规范文档。
    2. 集成Linter到开发流程，让工具“强制”统一。
    3. 在新人入职指引中加入命名规范，并在首次Code Review中重点指导。名称无法准确表达含义1. 使用了过于简短的缩写（如fnfor function）。
    2. 名称太泛（如data,info,handler）。
    3. 包含了类型信息（匈牙利命名法遗毒，如strName,iCount）。1.宁可长，不可含糊。calculateDiscount比calcDsc好得多。现代IDE有自动补全，长名称不是负担。
    2. 思考这个变量/函数代表的具体是什么。是userRegistrationData还是orderSummaryInfo？
    3. 避免匈牙利命名法。类型信息应由IDE和类型系统（如果是强类型语言）来提供，而不是名称。name而不是strName。布尔变量或函数命名混乱含义不清晰，无法直接判断其表示“是”或“否”的状态。布尔变量名应像一个问题，其值就是答案。使用is,has,can,should等前缀。例如：isValid,hasPermission,isEmpty()。避免使用flag,status这类模糊词。

    4.2 命名中的“信达雅”

    beyond规则，好的命名是一门艺术，追求“信、达、雅”。

    • 信：准确。名称必须精确反映所代表的事物或行为。getUserById明确表示通过ID获取用户，而getUser则模糊。
    • 达：简洁。在准确的前提下，尽可能简短。避免processDataAndGenerateReportAndSendEmail这种冗长的名字，可以拆分成processData(),generateReport(),sendReportByEmail()。
    • 雅：一致。在整个项目乃至整个团队的技术体系中，对同一概念使用相同的词汇。如果项目里同时出现了client,customer,user都指代“用户”，那就是灾难。应该在项目初期就定义好核心领域词汇表。

    4.3 处理特殊场景：复数、动词时态、前缀后缀

    • 复数：集合类变量使用复数形式，如users,orderList。但要注意，如果变量本身就是一个列表类型，List<User> userList这种“类型+类型”的命名（ListList）是冗余的，直接叫users更好。
    • 动词时态：函数名通常使用动词原形或动词短语，表示一个动作：fetch,calculate,render。查询类函数可用get/find，但get通常暗示轻量、快速的获取（可能来自缓存），find可能涉及搜索逻辑。布尔函数使用is/has等开头。
    • 前缀后缀：谨慎使用。m_（成员变量）、p（指针）这类前缀已基本被现代实践淘汰。但在特定框架或库中有约定俗成的用法，如Vue 3的ref返回值通常命名为xxxRef，这是为了在代码中提醒开发者这是一个响应式引用。遵循框架社区的约定比遵循通用规则更重要。

    命名是编程中最具复利效应的一项投资。初期多花几秒钟想一个好名字，会在未来的阅读、调试、重构中节省数小时的时间。它无声地传达着设计意图，是写给未来自己和其他维护者的第一份文档。掌握驼峰、帕斯卡、蛇形、烤串这四种最基本的工具，并在适当的场景坚定地使用它们，是写出干净、专业、可协作代码的第一步。

编程学习 学习日记 实战经验
← 返回列表