不同语言社区对于 文件（File） 和 目录（Directory） 的命名规范差异较大，通常是为了适应操作系统、文件系统或该语言的模块加载机制。以下是主流编程语言社区的命名规范整理：
| 元素 | 命名规范 | 示例 | 备注 |
|---|
模块文件 (.py) | 小写下划线 (Snake Case)，短小精悍。 | http_client.py, user_service.py | 避免使用连字符 (-)，否则在导入（import）时会被视为减号导致语法错误。 |
| 包/目录名 | 小写下划线，短小精悍。 | data_models, utilities | 通常不建议使用下划线，除非有必要。 |
| 类文件 | 通常为 小写下划线。 | 若类名为 UserManager，文件名为 user_manager.py | Python 不强制一个文件只包含一个类。 |
- 设计特点： 倾向于全小写和下划线，强调可读性，与 Unix/Linux 文件系统风格一致。
| 元素 | 命名规范 | 示例 | 备注 |
|---|
源文件 (.java) | 大驼峰 (Pascal Case)，必须 与文件中定义的 公共类名 完全一致。 | UserService.java, Application.java | 这是 JVM 的严格要求，不一致将导致编译失败。 |
| 包/目录名 | 全小写，通常使用 反向域名约定。 | com.example.projectname.dao | 目录结构严格反映包名。不使用下划线或连字符。 |
- 设计特点： 极其严格，强制要求文件名与类名匹配，是面向对象语言的典型特征。
| 元素 | 命名规范 | 示例 | 备注 |
|---|
文件 (.js, .ts) | 灵活多样，社区主流有以下几种： | | 项目内必须保持风格高度一致。 |
| 1. Kebab Case (小写连字符)：Node.js 社区和前端框架（React, Angular）主流。 | user-detail.js, api-client.ts | 浏览器和 URL 友好，是现代前端开发的首选。 |
| 2. Pascal Case (大驼峰)：文件主要导出一个 React 组件或 Class 时使用。 | UserList.jsx, Logger.ts | 方便与内部组件/类命名保持一致。 |
| 3. Camel Case (小驼峰)：有时用于工具或实用函数文件。 | utilityFunctions.js | 较少用于大型项目。 |
| 目录名 | 小写连字符 (Kebab Case) 或 小写驼峰 (Camel Case)。 | user-models, components | Kebab Case 更常见于现代前端项目。 |
- 设计特点： 灵活性高，但 Kebab Case 在前端生态中占据绝对优势，因其与 HTML/CSS 规范相契合。
| 元素 | 命名规范 | 示例 | 备注 |
|---|
源文件 (.cs) | 大驼峰 (Pascal Case)，必须 与文件中定义的 公共类名 完全一致。 | UserRepository.cs, ProductModel.cs | 与 Java 类似，属于编译器或项目约定的强制性要求。 |
| 命名空间/目录名 | 大驼峰，通常遵循公司/产品名称结构。 | ProjectName.Core.Services | 目录结构通常反映命名空间。 |
- 设计特点： 结构化强，文件名和目录名都倾向于使用大驼峰。
| 元素 | 命名规范 | 示例 | 备注 |
|---|
文件 (.go) | 小写下划线 (Snake Case)，或 全小写无下划线。 | server.go, http_util.go | 官方鼓励使用简洁的、全小写的名称。 |
| 包/目录名 | 全小写，不使用下划线或连字符。 | log, net, http | 强烈建议使用短小、有明确物理意义的单资产名称。 |
在制定项目的文件与目录命名规范时，请遵循以下核心原则：
| 规范要素 | 建议标准 | 理由 |
|---|
| 最优先原则 | 优先遵循语言社区标准 | 最大化代码的自然度，减少团队摩擦并避免工具链冲突。 |
| 文件命名 | 若文件包含单一类/组件： 采用该类/组件的命名风格（如 Java 用大驼峰，JS 组件用大驼峰）。 | 保证文件名与内部主要定义匹配，易于检索。 |
| 若文件是通用模块/工具集： 采用小写下划线（Python）或小写连字符（JS/Go）。 | 降低跨平台兼容性复杂度。 |
| 目录命名 | 全小写，避免使用下划线或连字符 (除非语言强制要求)。 | 目录名应保持简洁，仅代表其内部内容的逻辑分组。 |
| 大小写敏感 | 一律视为大小写敏感 | 虽然 Windows 对大小写不敏感，但 Linux/macOS 敏感。在版本控制（Git）中，大小写变化可能导致编译或打包异常，统一对待可避免跨平台部署出错。 |
| 命名唯一性 | 避免使用 util、manager、common 等 含义模糊的词语。 | 命名应清晰描述文件的 内容 和 目的，而非其抽象角色。 |