텍스트 및 일상 도구 · 텍스트 도구 키트
camelCase, snake_case, kebab-case 및 PascalCase: 각각이 사용되는 곳
· 배경
대소문자 변환 식별자 개발자 워크플로
명명 규칙에 대한 둘러보기 - 어디에서 왔는지, 어떤 언어와 생태계에서 어떤 것을 기대하는지, 그리고 파일 이름, URL, 데이터베이스 열 및 JSON 키가 각각 다른 방향을 가져오는 이유.
한 가지에 대한 5가지 이름 — 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에서 시연된 4가지 변환과 별도로 조립된 대문자 상수 형식
`camelCase`은 소문자 단어로 시작하고 이어지는 모든 단어의 시작을 대문자로 표시합니다. `PascalCase`은 첫 번째 단어도 대문자로 시작하면서 동일한 결합 단어 모양을 적용합니다. ToolAcre에서는 두 변환이 모두 동일한 단어 분할자로 시작되므로 구두점과 기존 대소문자 경계가 출력이 조합되기 전에 해석됩니다.
많은 팀이 두 가지 양식을 서로 다른 종류의 이름에 할당하지만 저장소는 해당 분할에 대한 범용 언어 규칙이나 기록을 설정하지 않습니다. 로컬 스타일 가이드, 린터, 프레임워크 API 또는 인근 코드를 권한으로 취급합니다. 변환기는 철자 모양을 변경합니다. 이름이 클래스, 함수, 변수 또는 구성 요소를 나타내는지 여부는 결정되지 않습니다.
camelCase와 PascalCase는 첫 글자가 다릅니다. 언어 기록이 저장소 증거 외부에 있습니다.
`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 슬러그가 나열되어 있지만 텍스트 라이브러리는 해당 소비자의 규칙을 정의하지 않습니다. 변환하기 전에 대상 구문을 확인하세요. ToolAcre에는 악센트 접기, 구분 기호 선택, 트리밍 및 선택적 길이 처리 기능을 갖춘 별도의 `slugify` 기능도 있으므로 일반적인 케밥 변환은 전체 URL-슬러그 유효성 검사로 표시되어서는 안 됩니다.
kebab-case 출력이 직접 지원됩니다. 유효한 용도는 주변 구문에 따라 다릅니다.
경계는 명명 규칙이 외관상이 아닌 작동이 되는 곳입니다. 브라우저 개체는 하나의 철자를 사용하고 API 페이로드 또는 데이터베이스 열은 다른 철자를 사용할 수 있습니다. 보기, 쿼리 및 비즈니스 논리 전반에 걸쳐 변환을 분산시키는 대신 하나의 어댑터에서 해당 매핑을 명시적으로 만듭니다. 예측 가능한 가장자리는 각 내부 모델의 일관성을 유지하고 불일치를 더 쉽게 찾을 수 있도록 합니다.
단지 식별자처럼 보인다는 이유만으로 임의의 값을 변환하지 마세요. 단어 분할기는 구두점을 경계로 처리하고 소문자, 대문자 및 숫자 사이의 선택된 전환을 인식합니다. 이는 이름에 유용하지만 철자가 외부에서 고정된 키를 변경할 수 있습니다. 수신 인터페이스가 귀하의 통제하에 있는 매핑을 문서화하지 않는 한 계약 키를 정확하게 보존하십시오.
실제 예 — 모든 규칙을 통해 하나의 식별자를 변환하고 소규모 프로젝트에서 어느 것이 속하는지 결정
`user profile ID`라는 문구가 포함된 소규모 애플리케이션을 생각해 보세요. ToolAcre는 카멜 케이스의 경우 `userProfileId`, 파스칼 케이스의 경우 `UserProfileId`, 스네이크 케이스의 경우 `user_profile_id`, 케밥 케이스의 경우 `user-profile-id`를 생성합니다. 각 출력에는 감지된 동일한 단어 3개가 포함되며, 대문자와 삽입된 구분 기호는 선택한 모양을 인코딩합니다.
실제 프로젝트에서는 JavaScript 개체에 `userProfileId`을 유지하고 이를 지속성 경계에서 `user_profile_id`에 명시적으로 매핑하고 문법이 하이픈을 허용하는 위치에 대해 `user-profile-id`을 예약할 수 있습니다. 정확한 선택은 해당 프로젝트에 속합니다. 중요한 부분은 모양을 반복적으로 추측하는 대신 각 경계를 문서화하고 매핑을 테스트하는 것입니다.
여기서 다루지 않는 내용 — 헝가리어 표기법 및 식별자 내부 약어에 대한 논쟁
이 비교는 약어 철자를 결정하지 않습니다. 구현에서는 감지된 단어를 다시 작성하기 전에 소문자로 변환하므로 `HTTP`을 포함하는 입력은 Pascal 또는 Camel 출력 내에서 `Http`로 나타날 수 있습니다. 팀이 `Http`, `HTTP`, `Id` 또는 `ID`를 선호하는지 여부는 이러한 일반 변환 외부에서 명시적인 예외가 필요한 명명 정책입니다.
또한 표기 기록, 언어 표준 또는 모든 유효한 식별자 문법을 다루지 않습니다. 이러한 주장에는 이 기사에 사용된 도구 파일 이상의 소스가 필요합니다. ToolAcre는 결정론적 텍스트 변환을 보여주고 한 가지 주요 제한 사항을 문서화합니다. 감지 가능한 경계 없이 작성된 화합물은 항상 사람이 의도한 단어로 분할될 수 없습니다.
약어 정책 및 표기 기록은 변환기 증거 외부에 있습니다.
보편적으로 올바른 사례는 없습니다. 이름은 계약을 따르고 해당 계층을 유지 관리하는 사람들이 계속 알아볼 수 있을 때 유용합니다. 이미 존재하는 규칙으로 시작하고, 하나의 양식을 경계 내에 유지하고, 다른 인터페이스에서 필요한 경우에만 번역하십시오. 일관성은 모든 생태계가 하나의 규칙을 공유하는 것처럼 가장하지 않고 부수적인 차이를 줄입니다.
경계에 다른 모양이 필요한 경우 식별자를 Text Toolkit 대소문자 변환기에 붙여넣고 하나를 적용하기 전에 4개의 출력을 검사하십시오. 작업은 브라우저에서 실행되며 매니페스트에는 텍스트가 서버로 전송되지 않거나 자동 저장되지 않는다고 명시되어 있습니다. 결과를 의도적인 매핑으로 사용한 다음 프로젝트 테스트와 로컬 스타일 검사를 통해 최종 선택을 확인합니다.