文字與日常工具·文字工具包
camelCase、snake_case、kebab-case 與 PascalCase：分別使用的位置
· 背景
大小寫轉換 標識符 開發人員工作流程
命名約定概覽 - 它們來自哪裡，哪些語言和生態系統期望哪些，以及為什麼檔案名稱、URL、資料庫列和 JSON 鍵各自朝著不同的方向發展。
一件事有五個名稱 — userProfileId、user_profile_id、user-profile-id、UserProfileId 和 USER_PROFILE_ID
片語「使用者設定檔 ID」可以變成 `userProfileId`、`UserProfileId`、`user_profile_id` 或 `user-profile-id`，而無需更改其單字。明顯的差異在於邊界出現的位置以及第一個單字是否以大寫開頭。 ToolAcre 直接從相同的輸入產生這四種形式，使它們的結構差異易於比較。
全大寫的 `USER_PROFILE_ID` 是另一個有用的專案約定，但它不是大小寫轉換器來源中的單獨組合選項。該工具包獨立地公開蛇形大小寫和大寫轉換。如果程式碼庫使用大寫常數，請轉換為蛇形命名法，然後將其大寫，而不是聲稱大小寫選單同時執行這兩個步驟。
Text Toolkit示範的四種轉換，加上單獨組裝的大寫常數形式
`camelCase` 以小寫單字開頭，並將後面每個單字的開頭大寫。 `PascalCase` 應用相同的連接詞形狀，同時也將第一個單字大寫。在 ToolAcre 中，兩個轉換都以相同的分詞器開始，因此在組裝輸出之前會解釋標點符號和現有的大小寫邊界。
許多團隊將這兩種形式指派給不同類型的名稱，但儲存庫並沒有建立通用語言規則或該分割的歷史記錄。將本機風格指南、linter、框架 API 或附近的程式碼視為權威。轉換器改變拼字形狀；它無法確定名稱是否代表類別、函數、變數或元件。
駝峰命名法和帕斯卡命名法的第一個字母不同；他們的語言歷史不在儲存庫證據之內
`snake_case` 降低每個偵測到的單字並用底線連接結果。對於 `User Profile ID`，ToolAcre 傳回 `user_profile_id`。分隔符號保持可見，當名稱通過無法可靠地保留大寫的系統時，這會有所幫助，但實際的好處並不能證明每個資料庫、語言或服務都需要下劃線。
使用目的地已定義的約定。 Python 服務可能有一個策略，另一個 SQL 模式，以及第三個序列化負載。 ToolAcre 無法檢查這些合約。它的可靠承諾範圍更窄： `toSnakeCase` 檢測單詞，將每個單詞小寫，然後在它們之間插入 `_` ，而不決定目的地是否允許或更喜歡該結果。
Snake_case輸出；生態系和 SQL 期望取決於每個項目
`kebab-case` 使用相同的小寫單詞，但用連字符將它們連接起來，產生 `user-profile-id`。在連字號被接受為資料的地方，例如配置的路線段或項目定義的檔名，該形狀在視覺上是清晰的。它不是 JavaScript 標識符，因為解析器可以將連字符讀取為運算符而不是名稱的一部分。
該大綱列出了 CSS 類別、HTML 屬性、命令列標誌和 URL slug，但文字庫並未定義這些使用者的規則。轉換前確認目標語法。 ToolAcre 還有一個單獨的 `slugify` 函數，具有重音折疊、分隔符號選擇、修剪和可選長度處理，因此普通的 kebab 轉換不應呈現為完整的 URL-slug 驗證。
kebab-case 輸出；有效的使用取決於周圍的語法
邊界是命名約定變得可操作而不是裝飾的地方。瀏覽器物件可以使用一種拼寫，而 API 負載或資料庫列則使用另一種拼寫。在一個適配器上明確映射，而不是在視圖、查詢和業務邏輯之間分散轉換。可預測的邊緣使每個內部模型保持一致，並使不匹配更容易定位。
避免僅僅因為任意值看起來像標識符而轉換它們。分詞器將標點符號視為邊界，並識別小寫、大寫和數字之間選定的轉換。這對於名稱很有用，但它可以改變拼字在外部固定的鍵。準確保留合約金鑰，除非接收介面記錄了您控制下的對應。
工作範例 — 透過所有約定轉換一個識別碼並決定哪個識別碼屬於小項目中的哪個位置
考慮一個帶有短語 `user profile ID` 的小型應用程式。 ToolAcre 為camel 情況產生`userProfileId`，為Pascal 情況產生`UserProfileId`，為snake 情況產生`user_profile_id`，為kebab 情況產生`user-profile-id`。每個輸出都攜帶相同的三個偵測到的單詞，而大寫和插入的分隔符號則對所選形狀進行編碼。
實際專案可能會將 `userProfileId` 保留在 JavaScript 物件中，將其明確地對應到持久邊界處的 `user_profile_id`，並為語法接受連字符的位置保留 `user-profile-id`。確切的選擇屬於該項目。重要的部分是記錄每個邊界並測試映射，而不是根據外觀反覆猜測。
這不包括什麼－匈牙利表示法和關於標識符內縮寫的爭論
此比較不會解決縮寫拼字問題。此實作在重建之前將偵測到的單字轉換為小寫部分，因此包含 `HTTP` 的輸入可能會在 Pascal 或 Camel 輸出中顯示為 `Http` 。團隊是否偏好 `Http`、`HTTP`、`Id` 還是 `ID` 是一種命名策略，需要在這些常規轉換之外有一個明確例外。
它也不涵蓋符號歷史、語言標準或每個有效的識別字語法。這些宣告所需的來源超出了本文所使用的工具檔案。 ToolAcre 示範了確定性文字轉換並記錄了一個關鍵限制：沒有任何可偵測邊界的書面複合字詞並不總是能被分割成人們想要的單字。
縮寫策略和符號歷史記錄位於轉換器證據之外
沒有一種情況是普遍正確的。當名稱遵循合約並仍然可以被維護該層的人員識別時，它是有用的。從已經存在的約定開始，將一種形式保留在邊界內，並僅在另一個介面需要它的地方進行翻譯。一致性減少了偶然的差異，而不假裝每個生態系統都共享一個規則。
當邊界確實需要另一種形狀時，請將標識符貼到文字工具包大小寫轉換器中，並在應用一個之前檢查四個輸出。該操作在瀏覽器中執行，並清單宣告文字不會發送到伺服器或自動保存。使用結果作為深思熟慮的映射，然後讓項目測試和本地樣式檢查確認最終選擇。