텍스트·정규식
camelCase와 snake_case 이름 표기 맞추기
사용할 도구
API는 user_id, 코드에서는 userId, CSS에서는 user-id를 쓰면 복사 실수나 검색 누락이 생길 수 있습니다. 이름 변환은 후보 비교 도구이지 의미를 이해하거나 참조를 리팩터링하는 기능이 아닙니다. 짧은 입력으로 단어 분리를 확인한 뒤 표기와 수정 위치를 정하세요.
세 단어의 여섯 표기 비교하기
user account iduser account id를 실행해 userAccountId, UserAccountId, user_account_id, user-account-id를 비교합니다. 세 단어의 순서가 유지되는지 보세요. 새 필드 하나를 보기 좋게 만드는 것보다 주변 코드나 수신 시스템의 규칙에 맞추는 것이 목적입니다.
USER_ACCOUNT_ID와 공백으로 구분된 소문자 형태도 나옵니다. 하이픈이나 공백은 언어와 문맥에 따라 다른 의미가 있으므로 모든 결과가 유효한 변수명은 아닙니다. 후보 생성과 식별자 유효성 검증을 구분하세요.
약어 경계는 직접 판단하기
HTTPServer
HTTP ServerHTTPServer와 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로 모입니다. 표기 통일에 유용하지만 다른 필드를 합쳐 버릴 수도 있습니다. 원래 이름과 새 이름의 대응표를 남기고 중복을 확인하세요. 변환은 반드시 되돌릴 수 있는 것이 아닙니다.
대소문자 차이를 구분하는지는 파일 시스템, DB, API마다 다릅니다. 눈에 다르게 보인다고 충돌이 없지는 않습니다. 예약어, 기존 변수, 파일이나 원격 등록 항목을 조회하는 도구가 아니므로 대상의 비교 규칙을 확인하세요.
API 필드와 내부 이름 변경을 분리하기
내부 변수를 userId로 바꿔도 API는 user_id를 요구할 수 있으므로 경계에서 명시적으로 매핑하세요. 전체 치환은 문서, 테스트, 문자열까지 바꿀 수 있습니다. 참조 추적 리팩터링과 고정 요청·응답 테스트로 외부 계약을 지킵니다.
규칙을 정하면 일반 단어, 약어, 숫자, 기존 구분자 예제를 몇 개 남기세요. 매번 추측해야 하는 규칙보다 예측 가능한 규칙이 유지하기 쉽습니다. 목표는 많은 문자열을 바꾸는 것이 아니라 다음 사람이 같은 개념에 같은 이름을 쓰게 하는 것입니다.