명명 규칙(프로그래밍)

Naming convention (programming)

컴퓨터 프로그래밍에서 명명규칙은 소스 코드 및 문서 내의 변수, 유형, 함수 및 기타 엔티티를 나타내는 식별자에 사용되는 문자 시퀀스를 선택하기 위한 규칙 세트이다.

명명 규칙을 사용하는 이유는 다음과 같습니다(프로그래머가 문자 시퀀스를 선택할 수 있는 것과는 반대).

  • 소스 [1]코드를 읽고 이해하는 데 필요한 노력을 줄입니다.
  • 코드 리뷰가 구문 및 명명 표준보다 더 중요한 문제에 초점을 맞출 수 있도록 합니다.
  • 코드 품질 검토 도구를 사용하여 구문 및 스타일 선호도 이외의 중요한 문제에 주로 보고서를 집중시킬 수 있습니다.

명명 규칙을 선택하는 것은 엄청난 논란이 될 수 있는데, 각 당의 당원들은 자신의 당원이 최고이고 다른 당원들은 열등하다고 생각한다.구어체로 이것은 [2]교의의 문제라고 한다.많은 기업이 독자적인 규약을 확립하고 있습니다.

잠재적인 이점

명명 규칙을 채택하면 다음과 같은 이점을 얻을 수 있습니다.

  • 식별자의 사용에 관한 추가 정보(즉, 메타데이터)를 제공한다.
  • 기대치를 공식화하고 개발팀 내의 일관성을 촉진하는 데 도움이 된다.
  • 오류 발생 가능성이 최소인 자동 리팩터링 또는 검색 및 교체 도구를 사용할 수 있도록 한다.
  • 잠재적 모호성의 경우 명확성을 향상시킨다.
  • 작업 제품의 미적 및 전문적 외관을 강화한다(예: 지나치게 긴 이름, 코믹하거나 "비꼬는" 이름 또는 약어를 허용하지 않음).
  • 서로 다른 조직의 작업 제품이 결합되었을 때 발생할 수 있는 "이름 충돌"을 방지하는 데 도움이 된다('네임스페이스' 참조).
  • 프로그램 소스 코드 및 모든 관련 문서를 제출해야 하는 프로젝트 양도 시 사용할 의미 있는 데이터를 제공한다.
  • 오랜 시간 후 코드 재사용 시 보다 잘 이해할 수 있도록 합니다.

과제들

명명규칙의 선택(및 그 적용 범위)은 종종 논쟁의 대상이 되고 있으며, 당원들은 자신들의 관점을 최고라고 생각하고 있고, 다른 사람들은 열등하다고 생각한다.또한 이미 알려진 명명 규칙이 제대로 정의되어 있더라도 일부 조직은 이를 일관되게 준수하지 못해 불일치와 혼란을 야기할 수 있습니다.명명규칙이 내부적으로 일관성이 없거나 임의적이거나 기억하기 어렵거나 유익한 것보다 부담이 더 큰 경우 이러한 과제는 더욱 악화될 수 있습니다.

가독성

식별자를 잘 선택하면 개발자와 분석가가 시스템이 무엇을 하고 있는지, 그리고 새로운 요구에 대응하기 위해 소스 코드를 수정하거나 확장하는 방법을 훨씬 쉽게 이해할 수 있습니다.

예를 들어,

 a = b * c;

구문적으로 정확하며 그 목적은 명확하지 않습니다.이것과 대조:

 weekly_pay = hours_displaces(시간) * 매시간_pay_rate;

적어도 문맥에 정통한 사람에게는 소스코드의 의도와 의미를 내포하고 있습니다.

실험에 따르면 식별자 스타일은 회수 및 정밀도에 영향을 미치며 스타일에 익숙하면 [3]회수 속도가 빨라집니다.

공통 요소

명명 규칙의 정확한 규칙은 사용되는 컨텍스트에 따라 달라집니다.그러나 오늘날 일반적으로 사용되는 명명 규칙에 영향을 미치는 몇 가지 공통 요소가 있습니다.

식별자 길이

모든 명명 규칙의 기본 요소는 식별자 길이(즉, 식별자에 허용되는 개별 문자의 유한 수)와 관련된 규칙입니다.일부 규칙은 고정된 숫자 경계를 지시하는 반면, 다른 규칙은 덜 정확한 휴리스틱 또는 지침을 지정합니다.

식별자 길이 규칙은 관례적으로 실무에서 경합되며, 학문적으로 많은 논쟁의 대상이 된다.

몇 가지 고려 사항:

  • 보다 간단한 식별자가 선호될 수 있습니다.왜냐하면 입력하기 쉽기 때문입니다(많은 IDE와 텍스트에디터는 텍스트 완성을 제공하여 이를 완화합니다).
  • 매우 짧은 식별자(예: 'i' 또는 'j')는 자동화된 검색 및 교체 도구를 사용하여 고유하게 구별하기가 매우 어렵습니다(단, 정규식 기반 도구의 경우 문제가 되지 않습니다).
  • 짧은 식별자가 충분한 정보를 인코딩할 수 없거나 너무 복잡해 보이기 때문에 긴 식별자가 선호될 수 있습니다.
  • 긴 식별자는 시각적 혼란으로 인해 선호되지 않을 수 있습니다.

일부 프로그래머가 더 긴 식별자보다 더 쉽게 타이핑하거나 생각하기 쉽기 때문에 짧은 식별자를 선호하는지 아니면 많은 상황에서 더 긴 식별자가 단순히 눈에 보이는 코드를 혼란스럽게 하고 인식된 추가 이점을 제공하지 않기 때문에 더 짧은 식별자를 선호하는지 여부는 공개되어 있는 연구 문제입니다.

프로그래밍의 간결성은 부분적으로 다음 요인에 기인할 수 있습니다.

  • 메모리 절약을 위해 변수 이름을 6자로 제한해야 했던 초기 링커.이후 "진행"에서는 인간이 이해하기 쉽도록 긴 변수 이름을 사용할 수 있었지만 처음 몇 글자만 중요했습니다.TRS-80 Level 2 Basic 등의 BASIC 일부 버전에서는 긴 이름이 허용되었지만 처음 두 글자만 의미가 있었습니다.이 기능을 통해 "VALUE" 및 "VAT"와 같은 이름이 사용되고 구별되도록 의도된 경우 등 디버깅이 어려울 수 있는 잘못된 동작이 허용되었습니다.
  • 자동 완성이 결여된 초기 소스 코드 편집기
  • 회선 길이가 제한된 초기 저해상도 모니터(예: 80자)
  • 변수 이름이 전통적으로 한 글자뿐인 수학에서 유래한 컴퓨터 과학의 많은 부분

대문자와 숫자

일부 명명 규칙은 문자를 대문자 또는 소문자로 표시할 수 있도록 제한합니다.다른 표기법에서는 대소문자를 제한하지 않고 대소문자를 기반으로 명확하게 정의된 해석을 부가합니다.일부 명명 규칙에서는 영숫자, 숫자 또는 영숫자 중 어느 문자를 사용할 수 있는지, 사용할 수 있는 경우 어떤 순서로 사용할지 지정합니다.

여러 단어 식별자

일반적인 권장 사항은 "의미 있는 식별자를 사용"입니다.하나의 단어가 여러 단어만큼 의미 있거나 구체적이지 않을 수 있습니다.따라서 일부 명명 규칙은 두 개 이상의 단어를 포함하는 "복합" 식별자를 처리하는 규칙을 지정합니다.

대부분의 프로그래밍 언어는 식별자에 공백을 허용하지 않기 때문에 각 단어를 구분하는 방법이 필요합니다(후속 독자들이 어떤 문자가 어떤 단어에 속하는지 쉽게 해석할 수 있도록 하기 위해).역사적으로 일부 초기 언어들, 특히 FORTRAN(1955년)과 ALGOL(1958)은 식별자 내에 공간을 허용하여 컨텍스트별로 식별자의 끝을 결정하였습니다.이것은 토큰화가 어려워 후대의 언어에서는 폐기되었습니다.단순히 단어를 연결함으로써 이름을 쓰는 것이 가능하며, 이것은 때때로 다음과 같이 사용된다.mypackageJava 패키지 [4]이름의 경우 읽기 쉬움이 더 오래 걸리지만 일반적으로 어떤 형태의 분리가 사용됩니다.

구분 기호로 구분된 단어

한 가지 방법은 영숫자가 아닌 문자로 구분하는 것입니다.이 목적으로 일반적으로 사용되는 두 문자는 하이픈("-")과 밑줄("_")입니다. 예를 들어 두 단어 이름 "입니다.two words"는 "로 표시됩니다.two-words" 또는two_words하이픈은 COBOL(1959), Forth(1970), Lisp(1958)를 쓰는 거의 모든 프로그래머에 의해 사용됩니다.또한 Unix에서는 명령어와 패키지에 공통적으로 사용되며 [5]CSS에서도 사용됩니다.이 표기법은 표준명은 없지만 리스프 케이스 또는 COBOL-CASE(Pascal 대소문자 비교), 케밥 케이스, 브로셰트 케이스 또는 기타 [6][7][8][9]변형이라고 할 수 있습니다.이 중 적어도 [10]2012년까지 거슬러 올라가는 케밥 케이스는 [11][12]그 이후로 어느 정도 통용되고 있다.

반면, FORTRAN/ALGOL 전통 언어, 특히 C와 파스칼 계열의 언어들은 감산 인픽스 연산자를 위해 하이픈을 사용했으며, 그 주위에 공백이 필요하지 않아 식별자에 사용할 수 없었다.다른 방법으로는 밑줄을 사용하는 것이 있습니다.이것은 C패밀리(Python 포함)에서 흔히 볼 수 있는 소문자로, 예를 들어 The C Programming Language(1978)에서 볼 수 있으며 snake case로 알려져 있습니다.UPER_CASE 와 같이 대문자가 붙은 밑줄은, 일반적으로, C 프리프로세서 매크로(MACRO_CASE) 및 UNIX 환경 변수(bash 의 BASH_VERSION 등)에 사용됩니다.때때로 이것은 유머러스하게 SCREAMING_SNAKE_CASE라고 불립니다.

대문자와 소문자로 구분된 단어

다음 항목도 참조하십시오.레터 케이스 special스페셜 케이스 스타일

또 다른 접근법은 "camelCase", "Pascal Case"라고 불리는 중간 대문자화 및 다른 많은 이름을 사용하여 단어 경계를 나타내므로 각각 ""를 렌더링합니다.two words" 로서.twoWords" 또는TwoWords". 이 규칙은 Pascal, Java, C# 및 Visual Basic에서 일반적으로 사용됩니다.식별자(예: 의 "XML" 및 "HTTP")에서의 이니셜리즘 처리XMLHttpRequest)는 다양합니다.일부에서는 소문자를 사용하도록 지시합니다(예:XmlHttpRequest입력, 가독성, 세그먼트화의 용이성을 높이는 한편, 그 외의 경우는 대문자로 표기합니다(예:XMLHTTPRequest)를 참조해 주세요.

여러 단어 식별자 형식의 예

여러 단어 식별자 형식
포맷 이름
twowords 플랫[13][14] 케이스
TWOWORDS 대문자[13]
twoWords (하위) camel Case, dromedary Case
TwoWords Pascal Case, Upper Camel Case, Studly[15] Case
two_words snake_case, pothole_case
TWO_WORDS 스크리밍 스네이크 케이스, 매크로 케이스, CONST_CASE
two_Words 카멜_뱀_케이스
Two_Words Pascal_Snake_Case, 제목_Case
two-words 케밥 케이스, 대시 케이스, 리스 케이스, 척추 케이스
TWO-WORDS 열차 케이스, 코볼 케이스, 스크리밍 케바 케이스
Two-Words 트레인 케이스,[13] HTTP[16] 헤더 케이스

메타데이터 및 하이브리드 표기법

명명규칙에 따라서는 특정 프로젝트 또는 문제 영역의 요건을 넘어 소프트웨어 아키텍처, 기본 프로그래밍 언어 또는 기타 종류의 교차 프로젝트 방법론에 의해 정의된 보다 중요한 일련의 원칙을 반영하는 규칙 또는 요건을 나타냅니다.

헝가리 표기법

아마도 가장 잘 알려진 표기법은 헝가리 표기법일 것입니다. 헝가리 표기법은 변수의 [17]이름에서 목적("Apps Hungari") 또는 유형("Systems Hungari")을 인코딩합니다.예를 들어 변수 szName의 접두사 "sz"는 변수가 늘 종단 문자열임을 나타냅니다.

위치 표기법

매우 짧은(8자 이하) 스타일에는 LCCIIL01이 있습니다.여기서 LC는 어플리케이션(신용장), C는 코볼, IIL은 특정 프로세스 서브셋, 01은 시퀀스 번호입니다.

이러한 종류의 규약은 JCL에 의존하는 메인프레임에서 여전히 사용되고 있으며 8.3(마침표 구분 기호와 3자 파일 형식) MS-DOS 스타일에서도 볼 수 있습니다.

복합어 구성표(OF Language)

IBM의 "OF Language"는 IMS(Information Management System) 매뉴얼에 문서화되어 있습니다.

PRIME-MODIPER-CLASS 단어 체계를 자세히 설명했는데, "고객 계정 번호"를 나타내기 위해 "CUST-ACT-NO"와 같은 이름으로 구성되었습니다.

PRIME 단어는 시스템에 관심 있는 주요 "엔티티"를 나타내기 위한 것이었다.

MODIFIER 단어는 추가 개선, 자격 부여 및 가독성을 위해 사용되었다.

CLASS 워드는 특정 응용 프로그램과 관련된 매우 짧은 데이터 유형 목록입니다.일반적인 CLASS 단어는 NO(번호), ID(식별자), TXT(텍스트), AMT(금액), QTY(수량), FL(플래그), CD(코드), W(작업) 등입니다.실제로 사용할 수 있는 CLASS 단어는 24개 미만의 용어 목록입니다.

CLASS 워드는 일반적으로 오른쪽(suffix)에 배치되어 헝가리 표기 접두사와 거의 같은 용도로 사용되었습니다.

CLASS 워드의 목적은 일관성뿐만 아니라 프로그래머에게 특정 데이터 필드의 데이터 유형을 지정하는 것이었습니다.BOUAL(2개의 값만) 필드를 받아들이기 전에 FL(플래그)은 가능한 값이 2개뿐인 필드를 나타냅니다.

언어 고유의 표기법

액션 스크립트

Adobe의 코딩 규칙 및 모범 사례에서는 ECMAScript와 대부분 일치하는 ActionScript의 [citation needed]명명 표준을 제안합니다.식별자 스타일은 Java와 유사합니다.

아다

에이다에서 유일하게 권장되는 식별자 스타일은Mixed_Case_With_Underscores를 클릭합니다.[18]

APL

APL 방언에서는 단어 간에 델타(δ)가 사용됩니다(예: PERFδSQUARE)(이전 APL 버전에는 소문자가 없었습니다).이름에 밑줄이 있는 경우 대신 델타 언더바(')가 사용됩니다.

C 및 C++

C 및 C++에서는 키워드와 표준 라이브러리 식별자는 대부분 소문자로 되어 있습니다.C 표준 라이브러리에서는 약칭이 가장 일반적입니다(예:isalnum문자가 영숫자인지 여부를 테스트하는 함수의 경우, C++ 표준 라이브러리는 종종 단어 구분 기호로 밑줄을 사용합니다(예:out_of_range매크로를 나타내는 식별자는 일반적으로 대문자와 밑줄만 사용합니다(이는 많은 프로그래밍 언어에서 상수에 모두 대문자 식별자를 사용하는 규칙과 관련이 있습니다).이중 밑줄 또는 밑줄과 대문자로 시작하는 이름은 구현용으로 예약되어 있으므로(컴파일러, 표준 라이브러리 등) 사용하지 마십시오.__reserved또는_Reserved이것은 표면적으로는 스트로핑과 비슷하지만 의미는 다릅니다.밑줄은 스트로핑과 같이 따옴표가 아니라 식별자 값의 일부입니다.[19][20]__foo이__foo(예약되어 있다), 아닌foo(단, 다른 네임스페이스에 있습니다.

C#

C# 의 명명 규칙은, 통상은 Microsoft 가 발표한 모든 것에 관한 가이드 라인에 따릅니다.NET[21] 언어( 를 참조).NET 섹션, 이하)을 참조해 주세요.단, C# 컴파일러에서는 규칙이 적용되지 않습니다.

Microsoft 가이드라인에서는, 다음의 제품만을 사용하는 것을 추천합니다.PascalCase그리고.camelCase후자는 메서드 파라미터 이름 및 메서드 로컬 변수 이름(method-local 포함)에만 사용됩니다.const값)을 참조해 주세요.Pascal Case에 대한 특별한 예외는 식별자를 시작하는 두 글자 머리글자 약자에 대해 작성됩니다. 이 경우 두 글자는 모두 대문자로 표시됩니다(예:IOStream); 이것은 긴 줄임말의 경우는 해당되지 않습니다(예를 들어,XmlStream이 가이드라인에서는, 한층 더 다음의 이름을 붙이는 것을 추천합니다.interface있다PascalCase대문자 앞에I와 같이IEnumerable.

필드 이름 지정에 관한 마이크로소프트의 가이드라인은 다음과 같습니다.static,public,그리고.protected필드; 필드 이외의 필드static기타 접근성 수준(예:internal그리고.private)는, 명시적으로 가이드 [22]라인의 대상이 되지 않습니다.가장 일반적인 관행은PascalCase다음 필드를 제외한 모든 필드의 이름에 대해private(둘 다)const도 아니다static） 에는, 를 사용하는 이름이 붙습니다.camelCase예를 들어 다음과 같은 단일 언더스코어 앞에 표시됩니다._totalCount.

모든 식별자 이름 앞에 commercial-at 기호를 붙일 수 있습니다.@의 의미에는 변화가 없습니다.즉, 둘 다factor그리고.@factor같은 오브젝트를 참조합니다.관례상 이 프리픽스는 ID가 예약된 키워드(예:for그리고.while프리픽스 또는 컨텍스트키워드(등)가 없는 경우는, ID 로서 사용할 수 없습니다.from그리고.where프레픽스가 엄밀하게 요구되지 않는 경우(최소한 선언에서는 필요 없음), 예를 들어 선언에서는 필요 없습니다.dynamic dynamic;유효합니다.일반적으로 이것은 다음과 같이 표시됩니다.dynamic @dynamic;후자가 변수 이름임을 독자에게 즉시 표시해야 합니다).

가세요

바둑에서 관례는 다음과 같습니다.MixedCaps또는mixedCaps여러 단어 이름을 쓰려면 밑줄이 아니라.구조 또는 함수를 참조할 때 첫 번째 문자는 외부 패키지의 가시성을 나타냅니다.첫 글자를 대문자로 하면 해당 코드가 내보내지고 소문자는 현재 [23]범위 내에서만 사용할 수 있습니다.

자바

Java에서는 Sun Microsystems,[24] [25]Netscape, AmbySoft [26]등과 같은 다양한 Java 커뮤니티에 의해 식별자에 대한 명명 규칙이 확립되고 제안되고 있습니다.Sun Microsystems가 설정한 명명 규칙의 예를 다음에 나타냅니다.여기서 "CamelCase"의 이름은 공백 없이 결합된 여러 단어로 구성됩니다.예를 들어 첫 번째 단어(대문자로 된 첫 글자)를 제외한 각 단어는 "camelCase"와 같습니다.

식별자 유형 명명 규칙 예
반 클래스 이름은 의 명사여야 합니다.UpperCamelCase각 단어의 첫 글자가 대문자로 표시됩니다.전체 단어를 사용합니다. 줄임말이나 줄임말을 사용하지 마십시오(URL이나 HTML과 같은 긴 형식보다 약어가 더 널리 사용되는 경우가 아니라면).
  • class Raster {}
  • class ImageSprite {}
방법들 메서드는 의 동사여야 합니다.lowerCamelCase또는 소문자 동사로 시작하는 다중 단어 이름, 즉 첫 번째 글자와 이후 단어의 첫 번째 글자가 대문자입니다.
  • run();
  • runFast();
  • getBackground();
변수 로컬 변수, 인스턴스 변수 및 클래스 변수도 다음과 같이 기술됩니다.lowerCamelCase변수 이름은 밑줄로 시작하지 마십시오( )._또는 달러 기호($둘 다 허용되더라도) 문자입니다.이는 모든 인스턴스 변수 프리픽스에 밑줄을 사용해야 한다는 다른 코딩 규칙과는 대조적입니다.

변수 이름은 짧지만 의미가 있어야 합니다.변수 이름의 선택은 니모닉(즉, 일상적인 관찰자에게 그 사용 의도를 나타내도록 설계)이어야 합니다.임시 "쓰러쉬" 변수를 제외하고 한 글자 변수 이름은 피해야 합니다.임시 변수의 일반적인 이름은 정수인 경우 i, j, k, m 및 n, 문자인 경우 c, d 및 e입니다.

  • int i;
  • char c;
  • float myWidth;
상수 상수는 밑줄로 구분하여 대문자로 작성해야 합니다.필요에 따라 상수 이름에는 숫자를 포함할 수도 있지만 첫 번째 문자로는 사용할 수 없습니다.
  • static final int MAX_PARTICIPANTS = 10;

Java 컴파일러는 이러한 규칙을 적용하지는 않지만 이를 따르지 않을 경우 혼란과 잘못된 코드가 발생할 수 있습니다.예를들면,widget.expand()그리고.Widget.expand()유의하게 다른 행동을 암시합니다.widget.expand()메서드에 대한 호출을 암시하다expand()라는 예시로widget,반면에.Widget.expand()스태틱 메서드에 대한 호출을 의미합니다.expand()수업 중에Widget.

널리 사용되는 Java 코딩 스타일은 다음과 같습니다.UpperCamelCase수업에 사용되다lowerCamelCase인스턴스 및 [24]메서드에 사용됩니다.이 사용법을 인식하기 위해 Eclipse와 같은 일부 IDE는 CamelCase를 기반으로 바로 가기를 구현합니다.예를 들어, Eclipse의 콘텐츠 지원 기능에서 CamelCase 단어의 대문자만 입력하면 일치하는 클래스 또는 메서드 이름이 나타납니다(예: "NPE"를 입력하고 콘텐츠 지원을 활성화하는 경우).NullPointerException).

세 글자 이상의 이니셜은 대문자 대신 Camel Case입니다(예:parseDbmXmlFromIPAddress대신parseDBMXMLFromIPAddress경계는 2글자 이상으로 설정할 수도 있습니다(예:parseDbmXmlFromIpAddress).

자바스크립트

내장된 JavaScript 라이브러리는 Java와 동일한 명명 규칙을 사용합니다.데이터 유형 및 생성자 함수는 대소문자를 사용합니다(RegExp,TypeError,XMLHttpRequest,DOMObject및 메서드는 소문자를 사용합니다( ).getElementById,getElementsByTagNameNS,createCDATASection)의 일관성을 유지하기 위해 대부분의 JavaScript 개발자는 다음 [27]규칙을 따릅니다.다음 항목도 참조하십시오.더글러스 크록포드의 규칙

리스프

대부분의 리스프 방언에서는 대시를 사용하여 식별자의 단어를 구분하는 것이 일반적입니다.with-open-file그리고.make-hash-table. 동적 변수 이름은 일반적으로 아스터리스크로 시작하고 끝납니다.*map-walls*. 상수 이름은 더하기 기호로 표시됩니다.+map-size+를 클릭합니다.[28][29]

.그물

Microsoft.NET 권장 사항UpperCamelCasePascal Case라고도 하며, 대부분의 식별자에 대해서는 Pascal Case 。(lowerCamelCase파라미터 및 변수)에 권장되며,의 공유 표기법입니다.NET [30]언어게다가 Microsoft 에서는, 타입 프리픽스 힌트(헝가리 표기법이라고도 불린다)는 [31]사용하지 않는 것을 추천합니다.헝가리 표기법을 사용하는 대신 기본 클래스의 이름으로 이름을 끝낼 것을 권장합니다.LoginButton대신BtnLogin를 클릭합니다.[32]

목표-C

Objective-C에는 Smalltalk에 뿌리를 둔 공통 코딩 스타일이 있습니다.

클래스, 프로토콜, 범주 및 글로벌 변수 및 함수와 같은 Objective-C 프로그램에서 사용되는 C 구조를 포함하는 최상위 엔티티는 다음과 같은 네임스페이스를 나타내는 짧은 전체 대문자 접두사를 가진 UpperCamelCase에 있습니다.NSString,UIAppDelegate,NSApp또는CGRectMake. 상수는 임의로 다음과 같은 소문자 "k"를 앞에 붙일 수 있습니다.kCFBooleanTrue.

오브젝트의 인스턴스 변수에서는 다음과 같이 언더스코어 앞에 lowerCamelCase를 사용합니다._delegate그리고._tableView.

메서드 이름에서는 다음과 같이 인수를 구분하는 콜론으로 구분된 여러 하위 Camel Case 부품을 사용합니다.application:didFinishLaunchingWithOptions:,stringWithFormat:그리고.isRunning.

파스칼, 모듈라-2 및 오베론

파스칼, 모듈라-2 및 오베론어는 일반적으로 다음과 같은 언어를 사용한다.Capitalized또는UpperCamelCase프로그램, 모듈, 상수, 유형 및 절차에 대한 식별자,lowercase또는lowerCamelCase산술 상수, 변수, 형식 매개변수 및 [33]함수의 식별자입니다.일부 방언은 식별자에서 밑줄과 달러 기호를 지원하지만 snake 대소문자와 매크로 대소문자는 외부 API 인터페이스 [34]내에서만 사용할 수 있습니다.

펄

Perl은 C의 전통에서 몇 가지 힌트를 얻습니다.로컬 범위 변수 및 서브루틴 이름은 infix 밑줄과 함께 소문자로 표시됩니다.서브루틴 및 개인으로 취급되는 변수에는 언더스코어가 붙습니다.패키지 변수는 제목으로 구분됩니다.선언된 상수는 모두 대문자입니다.패키지 이름은 pragmata를 제외한 camel 대소문자입니다.strict그리고.mro : 소문자입니다.[35][36]

PHP

PHP 권장사항은 PSR-1([37]PHP Standard Recommendation 1) 및 PSR-12에 포함되어 있습니다.PSR-1에 따르면 클래스 이름은 PascalCase, 클래스 상수는 MACRO_CASE, 함수 및 메서드 이름은 [38]camelCase여야 합니다.

파이썬과 루비

Python과 Ruby 둘 다 추천UpperCamelCase클래스명의 경우,CAPITALIZED_WITH_UNDERSCORES상수의 경우,snake_case다른 이름으로요.

Python에서는 이름이 "프라이빗"으로 되어 있으면 하나 또는 두 개의 밑줄 앞에 붙습니다(Python에서는 거의 해킹입니다).Python에서는 개인 변수가 규칙에 의해서만 적용됩니다.Python 키워드와의 경합을 방지하기 위해 이름에 밑줄을 붙일 수도 있습니다.접두사에 이중 밑줄을 사용하면 이름 망글링과 관련된 클래스 동작이 변경됩니다.두 개의 밑줄로 된 접두사와 접미사는 Python [39]개체에서 특별한 동작을 수행하는 "매직 이름"을 위해 예약되어 있습니다.

R

R의 정식 스타일 가이드는 없지만, R-guru Hadley Wickham의 깔끔한 스타일 가이드는 대부분의 [40]사용자에게 표준이 됩니다.이 가이드에서는 파일 이름에 특수 문자를 사용하지 않고 변수 및 함수 이름(예: fit_models)에 숫자, 문자 및 밑줄만 사용할 것을 권장합니다.r.

라쿠

Raku는 infix 하이픈을 사용할 수 있다는 점을 제외하고 Perl과 거의 동일한 규칙을 따릅니다.-또는 아포스트로피'(또는 작은 따옴표)는 알파벳 문자 뒤에 이어지는 경우 식별자(연속 2개 아님)따라서 Raku 프로그래머는 식별자에 케밥 케이스를 사용하는 경우가 많습니다.예를 들어 다음과 같습니다.fish-food그리고.don't-do-that유효한 식별자입니다.[41]

녹

녹이 슬어UpperCamelCase유형 에일리어스 및 구조, 특성, 열거 및 열거형 변형 이름에 대해서는SCREAMING_SNAKE_CASE상수 또는 정역학의 경우snake_case변수,[42] 함수 및 구조 부재 이름에 사용할 수 있습니다.

재빠르다

Swift는 각각의 릴리즈에 따라 명명 규칙을 변경했다.그러나 Swift 3.0의 주요 업데이트는 다음 명명 규칙을 안정시켰습니다.lowerCamelCase변수와 함수 선언에 걸쳐 있습니다.상수는 보통 열거형 또는 상수의 파라미터로 정의되며, 이 파라미터도 이와 같이 기술됩니다.클래스 및 기타 객체 유형 선언은 다음과 같습니다.UpperCamelCase.

Swift 3.0에서는 모든 서드파티 API에서 API 명명 및 선언 규칙을 표준화하기 위해 언어에 대한 명확한 명명 지침이 있습니다.[43]

「 」를 참조해 주세요.

레퍼런스

  1. ^ Derek M. Jones "연산자 이름은 연산자 우선 순위 결정에 영향을 미칩니다." 변수 이름이 연산자 우선 순위 선택에 미치는 영향을 조사하는 실험
  2. ^ Raymond, Eric S. (1 October 2004). "religious issues". The Jargon File (version 4.4.8 ed.). Retrieved 7 November 2011.
  3. ^ Binkley, Dave; Davis, Marcia (2009). "To CamelCase or Under_score" (PDF). 2009 IEEE 17th International Conference on Program Comprehension (17): 158–167. doi:10.1109/ICPC.2009.5090039. ISBN 978-1-4244-3998-0. S2CID 1450798.
  4. ^ 패키지 이름 지정
  5. ^ "CSS reference". Mozilla Developer Network. Retrieved 18 June 2016.
  6. ^ "StackOverflow – What's the name for snake_case with dashes?".
  7. ^ "Programmers – If this is camelCase what-is-this?".
  8. ^ "Camel_SNAKE-kebab". GitHub. September 2019.
  9. ^ UnderscoreVersusCapitalAndLowerCaseVariableNaming
  10. ^ jwfearn (5 September 2012). "Revisions to jwfearn's answer to What's the name for dash-separated case?".
  11. ^ 리빙 클로쥬르 (2015), Carin Meier 지음, 페이지
  12. ^ lodash: kebab Case
  13. ^ a b c "naming - What are the different kinds of cases?". Stack Overflow. Retrieved 16 August 2020.
  14. ^ "A brief list of programming naming conventions". deanpugh.com. 20 March 2018. Retrieved 16 August 2020.
  15. ^ "PSR-1: Basic Coding Standard - PHP-FIG". www.php-fig.org. Retrieved 4 September 2020.
  16. ^ "camel-snake-kebab". camel-snake-kebab. Retrieved 16 August 2020.
  17. ^ "Making Wrong Code Look Wrong". Joel on Software. 11 May 2005.
  18. ^ "3.2.1 Names - Chapter 3 - Ada 95 QUALITY AND STYLE Guide".
  19. ^ "ISO/IEC 9899:1999 Programming languages – C". ISO.
  20. ^ "ISO/IEC 14882:2011 Information technology – Programming languages – C++". ISO.
  21. ^ "Naming Guidelines". Microsoft.
  22. ^ "Names of Type Members". Microsoft.
  23. ^ "Effective Go - the Go Programming Language".
  24. ^ a b "Java 프로그래밍 언어에 대한 코드 표기법", 섹션 9: "명칭 표기법"
  25. ^ "Netscape's Software Coding Standards Guide for JAVA", Collab Software Coding Standards Guide for Java 2009년 3월 3일 Wayback Machine에서 아카이브됨
  26. ^ Amby Soft Inc.Java v17.01d의 부호화 규격
  27. ^ Morelli, Brandon (17 November 2017). "5 JavaScript Style Guides – Including AirBnB, GitHub, & Google". codeburst.io. Retrieved 17 August 2018.
  28. ^ "Variables".
  29. ^ CLiki에서의 명명 규칙
  30. ^ Microsoft.NET Framework 대문자의 스타일
  31. ^ .NET Framework 개발자 가이드– 일반 명명 규칙
  32. ^ [프레임워크 설계 가이드라인, Krzysztof Cwalina, Brad Abrams 62페이지]
  33. ^ 모듈라-2 명명 규칙
  34. ^ Modula-2 이름 표기법의 외부 API 식별자
  35. ^ "Perl style guide".
  36. ^ "perlmodlib – constructing new Perl modules and finding existing ones".
  37. ^ "PHP standards recommendations".
  38. ^ "PSR-1: Basic Coding Standard - PHP-FIG".
  39. ^ Python 코드 PEP8 스타일 가이드
  40. ^ RCode 스타일 가이드
  41. ^ "General rules of Perl 6 syntax".
  42. ^ "Naming conventions". doc.rust-lang.org. Retrieved 4 February 2018.
  43. ^ "swift.org API Design Guidelines".

외부 링크

  • coding-guidelines.com에는 언어학과 심리를 사용하여 식별자 명명 문제에 대한 비용/편익 분석을 시도하는 PDF가 있습니다.