命名規範:卡梅爾Case vs 蛇_case vs 餅-case vs 帕斯卡Case

菲爾·卡爾頓的著名笑話說電腦科學中只有兩件事是困難的:快取無效和命名。選擇好的詞已經很難了;然後你還必須決定如何加入它們。userId，user_id，UserId，user-id和USER_ID都描述了相同的概念，每個概念都在某個地方是正確的。這本指南解釋了主要的慣例，在哪裡預期每一個，以及如何處理尬的案例縮寫，數字和系統之間的界限。

主要會議

姓名	一個例子	典型使用情況
駝案例	getUserById	JavaScript/TypeScript變數和函式，Java方法，JSON欄位
帕斯卡案例	UserProfile	類，型別，反應元件，C#方法
蛇_案例	get_user_by_id	Python，Ruby，Rust函式，SQL列
叫的蛇案例	MAX_RETRIES	常數，環境變數
菜盒子	user-profile	網址，CSS類，HTML屬性，檔名，CLI標誌
列車外	Content-Type	HTTP頭
點.情況	app.server.port	配置鍵，Java包

一個case converter 可以同時翻譯所有這些名稱，在移動層之間時很方便。

根據語言和背景的公約

JavaScript和型別指令碼

• 變數，函式和物件屬性:camelCase。
• 類，介面，型別別名，名單和 React 元件:PascalCase。React 要求元件以大寫字母開始，以便 JSX 可以將它們與 HTML 元素區分開來。
• 真實常數 (永遠不會改變的配置):SCREAMING_SNAKE_CASE，儘管許多程式碼庫使用camelCase為const變數。
• 檔名稱:通常是元件檔案的kebab-case (user-profile.tsx) 或PascalCase。選擇一個;檔名中混合字母會導致檔案系統不敏感字母出現問題。

程式設計系統

PEP 8是明確的:函式，變數和模組的 snake_case，類的 PascalCase (PEP 8稱之為 CapWords)，模組級常數的 SCREAMING_SNAKE_CASE。一個領先的下劃線標誌著"內部":_cache。

現在就去吧

Go 使用 camelCase 和 PascalCase，小寫字母有意義:以大寫字母開始的識別符號從包中匯出，小寫字母是私有的。圍棋風格保留縮寫字母大寫:userID，HTTPServer，parseURL。

Java和C#

兩者都使用 PascalCase 為類和 camelCase 為區域性變數。Java 用 camelCase 為方法，C# 用 PascalCase 為方法和公有屬性。

腐蝕

函式，變數和模組的 snake_case;型別和特徵的 PascalCase;常數和靜態的 SCREAMING_SNAKE_CASE。編譯器會警告你，當你偏離。

SQL 資料庫

對於表格和列，snake_case是最安全的選擇。在 PostgreSQL 中，未引號的識別符號被摺疊成小寫，因此以 "userId" 建立的列必須永遠被引號，而 user_id 在任何地方都是有效的。桌面名稱是否單數 (user) 或多數 (users) 是團隊的偏好;一致性比選擇更重要。

CSS 和 HTML

CSS屬性是kebabcase (background-color)，所以類名稱通常是:.card-header。方法如BEM增加結構:.card__title--active。HTML屬性，包括data-*屬性，是小寫不敏感的，通常是小寫;JavaScript將data-user-id曝光為element.dataset.userId。

網址

用小寫的kebab-case來表示路徑:/blog/compress-image-to-100kb。關鍵字連結是最重要的。避免URL中大寫字母;許多伺服器將路徑視為小寫字母敏感，從而產生重複內容問題。

環境變數

SCREAMING_SNAKE_CASE：DATABASE_URL，STRIPE_SECRET_KEY。和容器平臺預計這種情況，有些不允許變數名字中連線。

縮寫詞和字母

這裡是團隊爭最多的地方。應該是parseHTTPResponse還是parseHttpResponse？userID還是userId？

• 將縮寫詞作為單詞 (parseHttpResponse，userId，XmlParser):微軟的.NET指南建議縮寫詞長於兩個字母，谷歌的Java和JavaScript風格指南以及許多TypeScript程式碼庫。它避免了像HTTPSURLConnection這樣的無法讀取的執行，並且在案例之間清晰地轉換parseHttpResponse自動變成parse_http_response。
• 保持縮寫字母大寫 (parseHTTPResponse，userID):在Go中是標準的，在舊的Java和Objective-C程式碼中是常見的。

自動轉換器將parseHTTPResponse分為解析/HTTP/響應，這很有效，但HTTPSURLConnection是模糊的。如果您控制了風格，將縮寫詞當作單詞更強大。

名字中的數字

保持數字附加到它們所屬的單詞:version2，utf8Decoder，base64_encode，h1-title。避免用數字開始識別符號;大多數語言禁止，並且用數字開始的CSS類需要逃離。

跨越邊界:API和資料庫

現實系統混合了慣例。一個使用snake_case的Python後端服務於一個 JavaScript前端，該前端預計camelCase，並由一個具有snake_case列的SQL資料庫支援。選項:

1. **使用線上的一個規範.**決定JSON使用camelCase (公共API最常見的選擇，匹配JavaScript) 或snake_case (Python和Ruby生態系統中常見，並由Stripe和GitHub等API使用)。記錄它並將其應用到任何地方。
2. 在邊緣轉換. 序列化庫可以自動轉換:Pydantic的別名生成器，傑克遜的PropertyNamingStrategies，或ORM列對映。在每個層內，程式碼仍然是語言。
3. 在一個有效載荷中不要混合.**{ "userId": 1, "created_at": "..." }是兩個世界中最壞的。

在生成JSON的TypeScript型別時，請將屬性名稱保持線上上，並在必要時轉換到對映層。

選擇好話語

案例的樣式是最簡單的部分。這裡有一些詞語規則:

• 具體說明，data，info和item沒有說什麼。invoiceLines可以說很多。
• 用於函式的動詞和用於值的名詞. calculateTotal()返回 total。
• Name booleans as questions. isActive，hasAccess，shouldRetry。
• 包括單元. timeoutMs，maxSizeBytes，durationSeconds 防止整個型別的蟲子。
• 避免使用縮寫，除非它們是通用的 (id，url，html)。usrCnt節省了四個字元，
• 匹配域名語言. 如果企業說"訂閱"，不要用程式碼稱之為plan。

執行公約

寫下這些規範，讓工具執行它們:ESLint的@typescript-eslint/naming-convention規則，Pylint和Ruff用於Python，golint和go vet，Rust的內建線條，以及CSS類模式的風格線條。自動化檢查結束了程式碼審查中的辯論，並保持了大型程式碼庫的一致性。

總結

使用camelCase用於JavaScript值，PascalCase用於型別和元件，snake_case用於Python，Rust和SQL，kebab-case用於URL，CSS和檔名，SCREAMING_SNAKE_CASE用於常數和環境變數。儘可能把縮寫詞當作單詞，將單元放在名字中，