程式設計中的命名慣例 — camelCase、snake_case 及更多

你第一次打開一個程式碼庫，在同一個檔案中看到了 getUserName、get_user_name 和 GetUserName。你立刻知道出了問題。命名慣例是那些在團隊合作之前看似微不足道，但之後變得至關重要的事情之一。

一致的命名不是個人偏好問題。它的目的是讓下一個接觸程式碼的人能夠讀懂它——而那個人通常是六個月後的你自己。

為什麼命名慣例很重要

當專案缺乏一致的命名時，三件事會崩潰：

• 可讀性下降 — 當變數風格每隔幾行就變化一次時，你的大腦會浪費週期來解析格式而不是理解邏輯
• 團隊協作分裂 — Pull request 變成了關於風格而非內容的戰場。由於沒有可預測的模式，新開發人員的入職需要更長時間
• 工具無法正常運作 — 程式碼檢查器、自動補全、程式碼生成器和重構工具都依賴於可預測的命名模式

你選擇哪種慣例遠不如選擇一種並堅持下去重要。一個在所有地方都使用一致 snake_case 的程式碼庫比混合三種不同風格的程式碼庫好得多。

命名慣例完全指南

camelCase

第一個單字小寫，後續每個單字首字母大寫。沒有分隔符。

// JavaScript / TypeScript
const userName = "Alice";
let itemCount = 42;
function getUserProfile(userId) {
  return fetchData(`/users/${userId}`);
}

使用場景： JavaScript、TypeScript 和 Java 使用 camelCase 作為變數、函式名和方法名。Swift 中也是區域變數和函式參數的預設寫法。

PascalCase

每個單字首字母大寫。也稱為 UpperCamelCase。

// TypeScript / C#
class UserProfile {
  firstName: string;
  lastName: string;
}

interface DatabaseConnection {
  host: string;
  port: number;
}

// React 元件
function NavigationBar({ items }: NavProps) {
  return <nav>{/* ... */}</nav>;
}

使用場景： C# 對幾乎所有公開成員使用 PascalCase — 類別、方法、屬性。TypeScript 和 JavaScript 將其用於類別、介面、型別別名和列舉。React 要求元件名使用 PascalCase，因為 JSX 需要區分元件和 HTML 元素。

在 Go 中，PascalCase 具有特殊含義：以大寫字母開頭的識別符是匯出的（公開的）。

snake_case

所有單字小寫，用底線分隔。

# Python
user_name = "Alice"
item_count = 42

def get_user_profile(user_id):
    return fetch_data(f"/users/{user_id}")

class UserProfile:
    def __init__(self, first_name, last_name):
        self.first_name = first_name
        self.last_name = last_name

使用場景： Python 對幾乎所有內容使用 snake_case，類別名除外。Ruby 遵循相同的模式。Rust 對變數、函式和模組使用 snake_case。資料庫架構幾乎普遍使用 snake_case 作為資料表名和欄位名。

SCREAMING_SNAKE_CASE

全部大寫加底線。保留給常數和不應更改的值。

// 大多數語言中的常數
const MAX_RETRY_COUNT = 3;
const API_BASE_URL = "https://api.example.com";
const DEFAULT_TIMEOUT_MS = 5000;

使用場景： 幾乎所有語言都使用 SCREAMING_SNAKE_CASE 作為常數。全大寫格式是一個通用信號，表示「不要重新賦值」。

kebab-case

全部小寫，用連字號作為分隔符。

/* CSS 類別名 */
.navigation-bar {
  background-color: #1a1a2e;
}

.user-profile-card {
  border-radius: 8px;
}

# CLI 旗標
npm install --save-dev eslint
git commit --no-verify

使用場景： CSS 和 HTML 強烈傾向於 kebab-case。URL slug 使用它。CLI 工具和命令列旗標也遵循它。

大多數程式語言中不能將 kebab-case 用於變數名，因為連字號會被解釋為減號運算子。

dot.case

用點分隔單字。

// Java 套件名
package com.example.userservice.controllers;

import org.springframework.boot.SpringApplication;

使用場景： Java 套件命名、檔案副檔名、Spring Boot 等框架中的組態屬性鍵。

Title Case

每個主要單字大寫。「and」、「the」、「of」等次要單字除非在短語開頭，否則保持小寫。

使用場景： UI 標題、頁面標題、選單項目、文件區段和專有名詞。

path/case

用斜線分隔單字，遵循檔案系統或命名空間慣例。

使用場景： 檔案系統路徑、模組路徑、命名空間層次和 URL 路由結構。

各語言慣例對照表

常見錯誤及修正方法

1. 在同一作用域中混合慣例

// ❌ 不一致
const user_name = "Alice";
const itemCount = 42;
const MaxRetries = 3;

// ✅ 一致的 camelCase
const userName = "Alice";
const itemCount = 42;
const maxRetries = 3;

2. 對語言使用錯誤的慣例

# ❌ 在 Python 中使用 camelCase
def getUserProfile(userId):
    userName = fetchUser(userId)
    return userName

# ✅ 使用 Python 期望的 snake_case
def get_user_profile(user_id):
    user_name = fetch_user(user_id)
    return user_name

3. 縮寫和首字母縮略詞

// ❌ 首字母縮略詞處理不一致
const XMLParser = new XmlParser();
const htmlToJSON = convert(HTMLString);

// ✅ 將首字母縮略詞視為單字
const xmlParser = new XmlParser();
const htmlToJson = convert(htmlString);

4. 布林值名稱沒有 is/has/can 前綴

// ❌ 歧義的布林值
const active = true;

// ✅ 明確的布林值意圖
const isActive = true;

慣例間的自動轉換

當你在不同語言之間工作時，手動轉換命名慣例既繁瑣又容易出錯。

我們的字串大小寫轉換器可以自動處理這個問題。貼上任何識別符，一鍵在 camelCase、PascalCase、snake_case、kebab-case 等之間轉換。

延伸閱讀

• JSON 格式化最佳實踐 — 像命名變數一樣乾淨地組織你的資料
• 正規表示式速查表 — 用於驗證和文字處理的模式比對參考
• SQL 格式化最佳實踐 — 撰寫可讀的 SQL 查詢

---

準備好自動轉換命名慣例了嗎？ 試試我們的字串大小寫轉換器 — 貼上任何識別符，在 camelCase、snake_case、PascalCase、kebab-case 等之間轉換。無需註冊，不向伺服器傳送資料，完全免費。