大小寫轉換工具

各種命名格式與適用場合

camelCase 以小寫開頭，之後每個單字首字母大寫，是 JavaScript、Java 與 Swift 中變數與函式的慣例。PascalCase 連第一個單字也大寫，通常保留給型別、類別與元件。snake_case 用底線連接小寫單字，是 Python、Ruby、Rust 與 SQL 識別碼的標準。SCREAMING_SNAKE_CASE 則是全大寫版本，幾乎只用於常數與環境變數。

kebab-case 用連字號連接小寫單字，適用於底線不方便或不易看見的地方：網址 slug、CSS 類別名稱與自訂屬性、HTML 屬性、命令列參數、npm 套件名稱。dot.case 則出現在設定鍵與具命名空間的設定中。

選哪一種很少是個人喜好的問題。每個生態系都有自己的慣例，Linter 會強制執行，而格式不對的識別碼放進檔案裡，讀起來就是格格不入。

拆分單字才是困難的部分

只要知道單字在哪裡，轉換格式就很容易，而找出單字正是簡單實作會出錯的地方。輸入會依底線、連字號、點與空格拆分，也會依大小寫的交界拆分，所以 userName 與 user_name 解析出來都是同樣兩個單字。

連續的大寫字母會被視為一個單字，而不是每個字母一個單字。XMLHttpRequest 會拆成 XML、Http、Request，得到 xml_http_request 而不是 x_m_l_http_request，getUserID 中的 ID 也會保持完整。規則是：連續的大寫字母若後面接著小寫字母，會在那個小寫字母前一個字元處結束，這讓 Http 的 H 成為新單字的開頭，而不是前一個單字的結尾。

數字會附在前面的單字上，所以 parseInt32 會拆成 parse、Int32。開頭與結尾的分隔符號會被移除，連續的分隔符號則會合併。

文章用格式與中日韓文字

Title Case 並不是把每個單字首字母都大寫。英文風格指南會讓冠詞、短介系詞與對等連接詞保持小寫，除非它們位於標題開頭或結尾，所以結果是 The Lord of the Rings，而不是 The Lord Of The Rings。各家指南對界線的畫法看法不一，尤其是四個字母以上的介系詞，如果這點很重要，請查閱你所採用的指南。Sentence case 只把第一個單字大寫、其餘不變，越來越多網站把它當作標題的標準寫法。

中文、日文與韓文完全沒有大小寫之分，所以這些字元會原封不動地通過。在混合文字中，只有拉丁字母的部分會被轉換。一段 CJK 文字會被視為一個單字，因為要切分成詞需要詞典與斷詞器，隨便猜測邊界只會產生看似篤定卻錯誤的結果。

來回轉換會遺失資訊

把識別碼轉成另一種格式再轉回來，不一定會得到原本的樣子。snake_case 轉 camelCase 再轉回來是安全的，因為底線的邊界會以大小寫交界的形式保留下來。但只要牽涉縮寫就不行：HTTPServer 會變成 http_server，再轉回來則是 HttpServer。HTTP 是縮寫這項資訊只存在於大寫之中，轉成小寫時就被丟掉了。

這在整個程式碼庫中重新命名時很重要，也是應該從原始名稱轉換一次、而不是串接多次轉換的原因。

為什麼命名慣例會有這麼多種

這些風格沒有誰比誰更好，它們是歷史的偶然，後來硬化成了社群標準。C 語言與其在 Unix 上的後代偏好小寫加底線，因為早期的連結器不分大小寫，而長名稱代價高昂。camelCase 由 Smalltalk 發揚，Java 承襲下來，而 JavaScript 因為當年緊跟 Java，又再承襲了一次。

Python 的風格指南明訂函式與變數用 snake_case、類別用 PascalCase，而那份文件的影響力，正是 Python 程式碼能跨專案保持一致外觀的原因，這是更早的語言從未做到的。CSS 與 HTML 選擇 kebab-case，一部分是因為它們的文法不分大小寫，一部分是因為在沒有識別子的語言中，連字號讀起來更自然。

實務上的結論是：正確的命名格式就是周圍生態系所使用的那一種。滿是 camelCase 的 Python 檔案之所以難讀，不是因為那種風格比較差，而是因為它打破了專案中其他每個檔案都遵循的模式。

跨越兩種慣例交界的地方

真實系統幾乎都至少有一處慣例會改變的接縫。PostgreSQL 的結構描述使用 snake_case，因為未加引號的識別子會被轉成小寫；它前面的 JSON API 通常使用 camelCase；消費那份 JSON 的 React 元件以 PascalCase 命名元件、以 camelCase 命名 props；而它算繪出的 CSS 類別則是 kebab-case。

在接縫處、而且只在一個地方轉換，是讓這一切保持可控的關鍵。ORM 與序列化函式庫幾乎都提供命名策略設定，正是為了這件事，使用它比手動對應每個欄位可靠得多，而手動對應正是拼錯字與「屬性悄悄不見」的來源。

唯一要避免的是轉換兩次，或在不同層以不同方向轉換。當一個欄位以 user_name 送達，在用戶端變成 userName，又以 userName 送回一個期待 user_name 的 API 時，這種不一致通常不會報錯，而是讓值被默默忽略。

在不弄壞程式的前提下跨程式碼庫重新命名

只有在最單純的情況下，重新命名才等於搜尋與取代。同一個識別子可能同時是變數、序列化用的字串、資料庫欄位、網址路徑與文件中的名稱，而這些並不是同一種變更：改變數名是安全的，改序列化的鍵則是破壞相容性的 API 變更。

行得通的順序是從原始名稱轉換一次，而不是串接多次轉換，因為縮寫無法在來回轉換中存活：HTTPServer 會變成 http_server，再轉回來則是 HttpServer。先產生完整的對應表，審查過後再套用。

長久的解法是 Linter。ESLint、Ruff、golint 及其同類可以對新程式碼強制命名慣例，讓那次大規模重新命名完成之後，同樣的問題不會再度出現。

並非每種語言的大小寫都很單純

轉大寫與轉小寫是與語言環境相關的操作，有幾個著名案例會讓天真的程式出錯。在土耳其文中，i 的大寫帶點，而 I 轉小寫會得到不帶點的字元，這就是為什麼在土耳其語環境下做不分大小寫的比較，可能無法匹配在英文中看起來完全相同的識別子。常見的防禦方式是：當文字是識別子而非一般文句時，使用不受語言環境影響的方式轉小寫。

德文的 ß 轉大寫會變成 SS，所以這個操作會改變字串長度，而且來回轉換不會回到原樣。希臘文的 sigma 有兩種小寫形式，取決於它是否位於字尾。這些都不影響 ASCII 識別子，也就是大多數程式碼，但全都會影響使用者輸入的文字。

本工具的轉換只作用於拉丁文字，日文、中文與韓文字元會原封不動保留，因為這些書寫系統根本沒有大小寫之分。

命名比程式碼活得更久

大小寫轉換是機械性的工作，挑選字詞則不是，而讀者真正卡住的正是字詞。一致的風格讓程式碼庫一眼就能讀懂，但一致地套用一個糟糕的名字，它仍然是個糟糕的名字。現在改名很便宜，等到這個識別子出現在 API、資料庫欄位與三個儀表板中之後就很昂貴了。

有幾個慣例值得遵守。布林值加上讓問題明確的前綴最好讀，例如 isActive、hasPermission、canEdit，因為單獨的 active 無法分辨它是狀態還是動作。集合用複數、單一項目用單數，所以是 users 與 user，而不是 userList。單位要寫進名字裡：timeoutMs、sizeBytes、priceCents。

不要縮寫到看不懂。usrMgr 省下的兩個字母，會讓未來每個讀者多花一點時間；而當程式碼庫一半寫 user、另一半寫 usr 時，搜尋就不再可靠。同義詞不一致也一樣：fetch、get、load 與 retrieve 在四個模組中做同一件事，是一筆永遠付下去的小額稅金，而選定其中一個是免費的。