文字與正規表示式
如何統一 camelCase 與 snake_case 命名？
使用工具
API 用 user_id，程式用 userId，CSS 用 user-id，容易抄錯或漏搜。命名轉換可比較候選，但不理解語意，也不會重構參照。先用短輸入確認分詞，再決定採用形式與修改位置。
比較三個單字的六種形式
user account id執行後比較 userAccountId、UserAccountId、user_account_id、user-account-id，確認三個詞順序不變。目的是符合既有程式或接收系統規則，不是單獨給新欄位選好看的形式。
還會輸出 USER_ACCOUNT_ID 與空白分隔的小寫形式，但不是每種形式都適用於所有語言變數名。連字號或空白可能有特殊含義，候選輸出不等於識別字合法性驗證。
縮寫邊界需要人工決定
HTTPServer
HTTP Server分別試 HTTPServer 與 HTTP Server。目前規則識別小寫或數字後接大寫，但不會推斷連續大寫中的 HTTP/Server 邊界，因此 camelCase 分別為 httpserver 與 httpServer。用空白明確意圖。
團隊對 Url 或 URL 也可能有不同約定。批次修改前先測試 API、ID、URL 並記錄例外。不瞭解分詞規則就大量套用，可能產生不符合既有預期的名稱。
數字與非英語詞不會自動翻譯
api v2 response結果為 apiV2Response 與 api_v2_response。v2 是否整體保留取決於輸入詞，工具不理解版本號。數字開頭的輸出也不自動成為目標語言合法識別字。
非英語文字不會翻譯或轉寫。要把日文客戶編號變成 customerId，先由人選擇 customer 與 id，再比較表記。把翻譯與格式轉換混為一談可能造成同一概念使用不同英文名。
不同名稱可能變成同一個結果
user-id、user_id、user id 會得到同一 camelCase。可整理表記，也可能合併不同欄位。保留舊名到新名對照並檢查重名，不要先丟原名；轉換不一定可逆。
僅大小寫不同的名稱是否相同取決於檔案系統、資料庫或 API。外觀不同不證明無衝突，應檢查目標比較規則。工具不會查詢保留字、變數、檔案或遠端註冊項。
區分 API 欄位與內部變數的修改
內部變數改成 userId 後，API 仍可能要求 user_id，應在邊界明確對應。全域替換會改到文件、測試與字串。程式重新命名用參照感知工具，固定請求回應測試保護契約。
確定規則後保留普通詞、縮寫、數字、既有分隔符等少量命名例。可預測的規範更易維護，目標是後來者能一致命名相同概念，而非機械轉換更多字串。