文本与正则表达式
如何统一 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，应在边界明确映射。全局替换会改到文档、测试和字符串。代码重命名用引用感知工具，固定请求响应测试保护协议。
确定规则后保留普通词、缩写、数字、已有分隔符等少量命名例。可预测的规范更易维护，目标是后来者能一致命名相同概念，而非机械转换更多字符串。