명명 규칙

컴퓨터 프로그래밍에서 명명 규칙(naming convention)은 변수, 자료형, 함수, 기타 소스 코드 및 문서의 엔티티를 나타내는 식별자에 사용할 문자 시퀀스를 선택하는 규칙 집합이다.

명명 규칙을 사용하는 이유(프로그래머가 어떤 문자 시퀀스든 선택할 수 있도록 허용하는 것과 반대로)는 다음과 같다:

 소스 코드를 읽고 이해하는 데 필요한 노력을 줄인다.Derek M. Jones "Operand names influence operator precedence decisions" An experiment investigating the effect of variable names on operator precedence selection
 코드 리뷰가 구문 및 명명 표준보다 더 중요한 문제에 집중할 수 있도록 한다.
 코드 품질 검토 도구가 구문 및 스타일 기본 설정 이외의 중요한 문제에 주로 보고서의 초점을 맞출 수 있도록 한다.

명명 규칙의 선택은 논란이 많은 문제일 수 있으며, 각 편은 자신의 규칙이 최고이고 다른 규칙은 열등하다고 주장한다. 구어적으로 이것은 교조주의의 문제라고 말한다. 많은 회사들도 자신들만의 규칙 집합을 확립했다.

 잠재적 이점 
명명 규칙의 이점은 다음과 같다:

 식별자가 사용되는 용도에 대한 추가 정보(즉, 메타데이터)를 제공한다.
 개발 팀 내에서 기대치를 공식화하고 일관성을 증진하는 데 도움을 준다.
 오류 가능성을 최소화하면서 자동화된 리팩터링 또는 검색 및 바꾸기 도구를 사용할 수 있도록 한다.
 잠재적 모호성이 있는 경우 명확성을 높인다.
 작업 산출물의 미적 및 전문적인 외관을 향상시킨다(예: 지나치게 긴 이름, 우스꽝스럽거나 "귀여운" 이름, 약어를 허용하지 않음으로써).
 다른 조직의 작업 산출물이 결합될 때 발생할 수 있는 "명명 충돌"을 피하는 데 도움을 준다(참조: 이름공간).
 프로그램 소스 코드 및 모든 관련 문서 제출을 요구하는 프로젝트 인계에 사용될 의미 있는 데이터를 제공한다.
 오랜 시간 후 코드 재사용 시 더 나은 이해를 제공한다.

 과제 

명명 규칙의 선택(및 그 시행 정도)은 종종 논란이 많은 문제이며, 각 편은 자신의 관점이 최고이고 다른 관점은 열등하다고 주장한다. 더욱이, 잘 알려져 있고 잘 정의된 명명 규칙이 마련되어 있더라도 일부 조직은 이를 일관성 있게 준수하지 못하여 불일치와 혼란을 야기할 수 있다. 이러한 문제는 명명 규칙이 내부적으로 일관성이 없거나, 임의적이거나, 기억하기 어렵거나, 또는 이점보다 부담이 더 크다고 인식될 경우 악화될 수 있다.

 가독성 
잘 선택된 식별자는 개발자와 분석가가 시스템이 무엇을 하는지, 그리고 새로운 요구 사항을 적용하기 위해 소스 코드를 어떻게 수정하거나 확장할지 이해하는 것을 훨씬 쉽게 만든다.

예를 들어,
 a = b * c;

는 구문적으로 올바르지만, 그 목적은 명확하지 않다. 다음 코드와 비교해 보자:
 weekly_pay = hours_worked * hourly_pay_rate;

이것은 적어도 해당 문의 맥락에 익숙한 사람들에게는 소스 코드의 의도와 의미를 암시한다.

실험에 따르면 식별자 스타일은 회상 및 정확성에 영향을 미치며, 스타일에 대한 친숙도는 회상 속도를 높인다.

 공통 요소 

명명 규칙의 정확한 규칙은 사용되는 컨텍스트에 따라 다르다. 그럼에도 불구하고, 오늘날 일반적으로 사용되는 모든 명명 규칙에 영향을 미치는 몇 가지 공통 요소가 있다.

 식별자 길이 

모든 명명 규칙의 기본 요소는 식별자 길이(즉, 식별자 내에서 허용되는 개별 문자의 유한 개수)와 관련된 규칙이다. 일부 규칙은 고정된 숫자 제한을 지시하는 반면, 다른 규칙은 덜 정확한 발견적 방법이나 지침을 지정한다.

식별자 길이 규칙은 실제로는 일상적으로 논쟁의 대상이 되며, 학술적으로도 많은 토론이 이루어진다.

몇 가지 고려 사항:
 더 짧은 식별자는 더 편리하기 때문에 선호될 수 있는데, 입력하기가 더 쉽기 때문이다(비록 많은 IDE와 텍스트 편집기가 텍스트 완성을 제공하여 이를 완화하지만).
 'i' 또는 'j'와 같은 극도로 짧은 식별자는 자동 검색 및 바꾸기 도구를 사용하여 고유하게 구별하기가 매우 어렵다(비록 정규식 기반 도구에는 문제가 되지 않지만).
 더 긴 식별자는 짧은 식별자가 충분한 정보를 인코딩할 수 없거나 너무 암호처럼 보이기 때문에 선호될 수 있다.
 더 긴 식별자는 시각적 혼란 때문에 선호되지 않을 수 있다.

일부 프로그래머들이 더 짧은 식별자를 선호하는 이유가 더 길게 입력하거나 생각하기 쉽기 때문인지, 아니면 많은 상황에서 더 긴 식별자가 단순히 보이는 코드를 복잡하게 하고 인지되는 추가적인 이점을 제공하지 않기 때문인지는 미해결 연구 문제이다.

프로그래밍에서의 간결성은 부분적으로 다음과 같은 요인에 기인할 수 있다:
 메모리를 절약하기 위해 변수 이름을 6자로 제한해야 했던 초기 링커. 이후의 "진보"로 인해 사람의 이해도를 위해 더 긴 변수 이름을 사용할 수 있게 되었지만, 처음 몇 문자만 유의미했다. TRS-80 레벨 2 베이직과 같은 일부 베이직 버전에서는 긴 이름이 허용되었지만, 처음 두 문자만 유의미했다. 이 기능은 "VALUE"와 "VAT"와 같은 이름이 사용되어 서로 다른 것으로 의도되었을 때 디버그하기 어려운 오류 동작을 허용했다.
 자동 완성 기능이 없는 초기 소스 코드 편집기
 제한된 줄 길이(예: 80자만)를 가진 초기 저해상도 모니터
 컴퓨터 과학의 많은 부분이 전통적으로 변수 이름이 한 글자인 수학에서 유래했다는 점

 대소문자 및 숫자 

일부 명명 규칙은 문자가 대문자로 나타날 수 있는지 또는 소문자로 나타날 수 있는지 제한한다. 다른 규칙은 대소문자를 제한하지 않지만, 대소문자에 기반한 잘 정의된 해석을 부여한다. 일부 명명 규칙은 알파벳, 숫자 또는 영숫자 문자를 사용할 수 있는지 여부와, 그렇다면 어떤 순서로 사용할 수 있는지 지정한다.

 여러 단어 식별자 

일반적인 권장 사항은 "의미 있는 식별자를 사용하라"이다. 단일 낱말은 여러 단어만큼 의미 있거나 구체적이지 않을 수 있다. 결과적으로 일부 명명 규칙은 둘 이상의 단어를 포함하는 "복합" 식별자 처리에 대한 규칙을 지정한다.

대부분의 프로그래밍 언어는 식별자에 공백을 허용하지 않으므로, 각 단어를 구분하는 방법이 필요하다(후속 독자가 어떤 문자가 어떤 단어에 속하는지 해석하기 쉽게 만들기 위해). 역사적으로 일부 초기 언어, 특히 포트란 (1955) 및 알골 (프로그래밍 언어) (1958)는 식별자 내에 공백을 허용했으며, 컨텍스트에 의해 식별자의 끝을 결정했다. 이는 토큰화의 어려움 때문에 이후 언어에서 폐기되었다. 단순히 단어를 연결하여 이름을 작성할 수 있으며, 이는 때때로 자바 패키지 이름에 mypackage와 같이 사용되지만,Naming a Package 용어가 길어지면 가독성이 떨어지므로 일반적으로 어떤 형태의 분리가 사용된다.

 구분 문자로 분리된 단어 

한 가지 접근 방식은 별도의 단어를 비영숫자 문자로 구분하는 것이다. 이 목적으로 일반적으로 사용되는 두 문자는 붙임표("-"")와 밑줄 문자("_"); 예를 들어, 두 단어 이름 "two words"는 "two-words" 또는 "two_words"로 표시된다.

붙임표는 코볼 (1959), 포스 (1970), 리스프 (1958)를 작성하는 거의 모든 프로그래머가 사용한다. 또한 유닉스에서 명령 및 패키지에 일반적으로 사용되며 CSS에도 사용된다. 이 규칙은 표준 이름이 없지만, lisp-case 또는 COBOL-CASE (파스칼 케이스와 비교), kebab-case, brochette-case 또는 다른 변형으로 언급될 수 있다.UnderscoreVersusCapitalAndLowerCaseVariableNaming 이들 중 적어도 2012년부터 사용된 kebab-case는 이후 어느 정도 통용되었다.Living Clojure (2015), by Carin Meier, p. 91lodash: kebabCase

대조적으로, 포트란/알골 전통의 언어, 특히 C 및 파스칼 계열의 언어는 뺄셈 중위 연산자에 붙임표를 사용했으며, (자유 형식 언어이므로) 그 주변에 공백을 요구하고 싶지 않아 식별자에서 그 사용을 막았다.

대안은 밑줄을 사용하는 것이다. 이것은 C 계열 (파이썬 포함)에서 소문자 단어와 함께 일반적이며, 예를 들어 C 프로그래밍 언어 (책) (1978)에서 발견되었으며, 스네이크 표기법 또는 snail case로 알려지게 되었다. UPPER_CASE와 같이 대문자와 함께 밑줄은 C 전처리기 매크로에 일반적으로 사용되며, 따라서 MACRO_CASE로 알려져 있고, 배시의 BASH_VERSION과 같은 유닉스 환경 변수에도 사용된다. 때때로 이것은 유머러스하게 SCREAMING_SNAKE_CASE (또는 SCREAMING_SNAIL_CASE)로 언급된다.

 대소문자로 분리된 단어 

또 다른 접근 방식은 "카멜 표기법", "파스칼 케이스" 및 기타 여러 이름으로 불리는 중간 대문자화를 사용하여 단어 경계를 나타내는 것으로, "two words"를 각각 "twoWords" 또는 "TwoWords"로 렌더링한다. 이 규칙은 일반적으로 파스칼, 자바, C# 및 비주얼 베이직에서 사용된다. 식별자 내에서 두문자어(예: XMLHttpRequest의 "XML" 및 "HTTP")의 처리는 다양하다. 일부는 타이핑, 가독성 및 분할 용이성을 위해 소문자(예: XmlHttpRequest)로 해야 한다고 지시하는 반면, 다른 일부는 정확성을 위해 대문자(예: XMLHTTPRequest)로 남겨둔다.

 여러 단어 식별자 형식의 예시 
+여러 단어 식별자 형식형식이름twowordsflatcaseTWOWORDSUPPERCASE, SCREAMINGCASEtwoWords(하위) camelCase, dromedaryCaseTwoWordsPascalCase, UpperCamelCasetwo_wordssnake_case, snail_case, pothole_caseTWO_WORDSALL_CAPS, SCREAMING_SNAKE_CASE, MACRO_CASE, CONSTANT_CASEtwo_Wordscamel_Snake_CaseTwo_WordsPascal_Snake_Case, Title_Casetwo-wordskebab-case, dash-case, lisp-case, spinal-caseTWO-WORDSTRAIN-CASE, COBOL-CASE, SCREAMING-KEBAB-CASETwo-WordsTrain-Case, HTTP-Header-Case

 메타데이터 및 하이브리드 규칙 
일부 명명 규칙은 특정 프로젝트나 문제 영역의 요구 사항을 넘어선 규칙 또는 요구 사항을 나타내며, 대신 소프트웨어 구조, 기본 프로그래밍 언어 또는 다른 종류의 프로젝트 간 방법론에 의해 정의된 더 큰 포괄적인 원칙 집합을 반영한다.

 헝가리안 표기법 

아마도 가장 잘 알려진 것은 헝가리안 표기법인데, 이는 변수 이름에 변수의 목적("앱 헝가리안") 또는 자료형("시스템 헝가리안")을 인코딩한다. 예를 들어, 변수 szName의 접두사 "sz"는 해당 변수가 null로 종료되는 문자열임을 나타낸다.

 위치 표기법 

매우 짧은 (8자 이하) 스타일에 사용되는 형식은 다음과 같다: LCCIIL01, 여기서 LC는 응용 프로그램 (Letters of Credit)을, C는 코볼을, IIL은 특정 프로세스 하위 집합을, 그리고 01은 시퀀스 번호를 나타낸다.

이러한 종류의 규칙은 JCL에 의존하는 메인프레임에서 여전히 활발히 사용되고 있으며, 8.3 (마침표 구분 기호 뒤에 세 문자 파일 형식으로 최대 8자) MS-DOS 스타일에서도 볼 수 있다.

 복합 단어 체계 (OF 언어) 

IBM의 "OF 언어"는 IMS (정보 관리 시스템) 매뉴얼에 문서화되어 있었다.

이는 "고객 계정 번호"를 나타내는 "CUST-ACT-NO"와 같은 이름을 포함하는 PRIME-MODIFIER-CLASS 단어 체계를 자세히 설명했다.

PRIME 단어는 시스템에 중요한 주요 "엔티티"를 나타내도록 의도되었다.

MODIFIER 단어는 추가적인 정제, 한정 및 가독성을 위해 사용되었다.

CLASS 단어는 특정 응용 프로그램과 관련된 매우 짧은 데이터 유형 목록이어야 했다. 일반적인 CLASS 단어는 다음과 같을 수 있다: NO (number), ID (identifier), TXT (text), AMT (amount), QTY (quantity), FL (flag), CD (code), W (work) 등. 실제로는 사용 가능한 CLASS 단어는 20개 미만의 용어 목록이었다.

CLASS 단어는 일반적으로 오른쪽에 위치하며 (접미사), 헝가리안 표기법 접두사와 거의 동일한 목적을 수행했다.

CLASS 단어의 목적은 일관성 외에도 특정 데이터 필드의 자료형을 프로그래머에게 지정하는 것이었다. BOOLEAN (두 값만) 필드가 받아들여지기 전에, FL (flag)은 두 가지 가능한 값만 있는 필드를 나타냈다.

 언어별 규칙 
 액션스크립트 
어도비의 코딩 컨벤션 및 모범 사례는 ECMA스크립트와 대부분 일치하는 액션스크립트 명명 표준을 제안한다. 식별자의 스타일은 자바스크립트의 스타일과 유사하다.

 에이다 
에이다에서는 Mixed_Case_With_Underscores 스타일의 식별자만 권장된다.

 APL 
APL 방언에서는 단어 사이에 델타(Δ)가 사용된다(예: PERFΔSQUARE; 구형 APL 버전에서는 전통적으로 소문자가 존재하지 않았다). 이름이 밑줄 문자를 사용한 경우, 델타 언더바(⍙)가 대신 사용되었다.

 C 및 C++ 
C 및 C++에서 키워드와 표준 라이브러리 식별자는 대부분 소문자이다. C 표준 라이브러리에서는 약어 이름이 가장 일반적이며(예: 문자가 영숫자인지 테스트하는 함수에 대한 isalnum), C++ 표준 라이브러리는 종종 밑줄을 단어 구분 기호로 사용한다(예: out_of_range). 매크로를 나타내는 식별자는 관례적으로 대문자와 밑줄만 사용하여 작성된다(예: NULL 및 EINVAL). 이는 많은 프로그래밍 언어에서 상수에 대해 모두 대문자 식별자를 사용하는 관례와 관련이 있다. 이중 밑줄을 포함하거나 밑줄과 대문자로 시작하는 이름은 구현(컴파일러, 표준 라이브러리)을 위해 예약되어 있으므로 사용해서는 안 된다(예: __reserved 또는 _Reserved). 이는 겉으로는 스트로핑과 유사하지만, 의미론이 다르다. 밑줄은 식별자 값의 일부이지 따옴표 문자(스트로핑처럼)가 아니다. __foo의 값은 __foo(예약됨)이며, foo(하지만 다른 이름공간에 있음)가 아니다.

C++에는 여러 명명 규칙이 존재하지만, 단일 규칙이 지배적이지는 않다. C++ 표준 라이브러리와 Boost 라이브러리는 를 사용하지만(예: std::unordered_map), 자바와 유사한 와 가 C++에서 더 인기가 있을 수 있다(예: absl::Exponential).

 C 샤프 
C# 명명 규칙은 일반적으로 모든 .NET 언어에 대해 마이크로소프트가 게시한 지침을 따르지만 (아래 .NET 섹션 참조), C# 컴파일러에 의해 어떤 규칙도 강제되지 않는다.

마이크로소프트 지침은 대부분의 식별자에 대해 PascalCase와 camelCase만을 사용할 것을 권장하며, 후자는 메서드 매개변수 이름과 메서드 로컬 변수 이름(메서드 로컬 const 값 포함)에만 사용된다. PascalCase의 특별한 예외는 식별자를 시작하는 두 글자 두문자어에 대해 만들어진다. 이 경우 두 글자 모두 대문자이다(예: IOStream). 더 긴 두문자어에는 해당되지 않는다(예: XmlStream). 지침은 또한 interface에 부여되는 이름이 IEnumerable과 같이 대문자 I가 앞에 붙은 PascalCase가 되도록 권장한다.

필드 명명에 대한 마이크로소프트 지침은 static, public 및 protected 필드에만 해당되며, static이 아니고 다른 접근성 수준(예: internal 및 private)을 가진 필드는 지침에 명시적으로 포함되지 않는다. 가장 일반적인 관행은 모든 필드 이름에 PascalCase를 사용하는 것이지만, private(및 const도 static도 아닌) 필드의 경우 단일 밑줄이 앞에 붙은 camelCase를 사용하는 이름이 지정된다(예: _totalCount).

모든 식별자 이름에는 상업용 @ 기호(@)를 접두사로 붙일 수 있으며, 의미 변화는 없다. 즉, factor와 @factor는 동일한 객체를 참조한다. 관례적으로 이 접두사는 식별자가 예약된 키워드(예: for 및 while)여서 접두사 없이는 식별자로 사용할 수 없는 경우, 또는 문맥 키워드(예: from 및 where)여서 접두사가 엄격하게 요구되지 않는 경우에만 사용된다(적어도 선언 시에는 그렇지 않다. 예를 들어, dynamic dynamic; 선언은 유효하지만, 독자에게 후자가 변수 이름임을 즉시 알리기 위해 일반적으로 dynamic @dynamic;으로 표시될 것이다).

 다트/플러터 

플러터 SDK에서 사용되는 다트 언어의 규칙은 자바와 유사하지만, 상수는 lowerCamelCase로 작성된다는 점이 다르다.
다트는 밑줄(_)로 시작하는 비지역 식별자를 비공개로 취급하는 구문 규칙을 강제한다(이 언어에는 public 또는 private 접근을 위한 명시적 키워드가 없기 때문이다).
또한 소스 파일 이름은 자바의 "소스 파일당 하나의 public 클래스, 이름이 일치해야 함" 규칙을 따르지 않고, 파일 이름에 snake_case를 사용한다.

 Go 
Go에서는 여러 단어로 된 이름을 작성할 때 밑줄 대신 MixedCaps 또는 mixedCaps를 사용하는 것이 관례이다. 구조체나 함수를 참조할 때 첫 글자는 외부 패키지에 대한 가시성을 지정한다. 첫 글자를 대문자로 만들면 해당 코드 조각이 내보내지고, 소문자로 만들면 현재 범위 내에서만 사용할 수 있다.

 자바 
자바에서는 Sun Microsystems,"Code Conventions for the Java Programming Language", Section 9: "Naming Conventions" Netscape,"NETSCAPE'S SOFTWARE CODING STANDARDS GUIDE FOR JAVA",Collab Software Coding Standards Guide for Java  AmbySoft"AmbySoft Inc. Coding Standards for Java v17.01d" 등 다양한 자바 커뮤니티에서 식별자 명명 규칙을 수립하고 제안했다. Sun Microsystems에서 정한 명명 규칙의 예시는 다음과 같다.
"카멜 표기법"에서 이름은 공백 없이 연결된 여러 단어로 구성되며, 첫 단어를 제외한 각 단어의 첫 글자는 대문자이다(예: "camelCase").
 식별자 유형 명명 규칙 예시 클래스 클래스 이름은 Upper카멜 표기법 형식의 명사여야 하며, 각 단어의 첫 글자는 대문자로 시작해야 한다. 전체 단어를 사용하고, 약어 및 축약어는 피해야 한다(단, URL 또는 HTML과 같이 약어가 긴 형식보다 훨씬 더 널리 사용되는 경우는 제외). class Raster {}
 class ImageSprite {} 메서드 메서드는 lower카멜 표기법 형식의 동사 또는 소문자로 시작하는 동사가 포함된 여러 단어 이름이어야 한다. 즉, 첫 글자는 소문자이고 그 이후 단어의 첫 글자는 대문자이다. run();
 runFast();
 getBackground(); 변수 지역 변수, 인스턴스 변수, 클래스 변수 또한 lower카멜 표기법으로 작성된다. 변수 이름은 밑줄(_) 또는 달러 기호($) 문자로 시작해서는 안 되지만, 둘 다 허용된다. 이는 모든 인스턴스 변수에 밑줄을 접두사로 사용해야 한다고 명시하는 다른 코딩 컨벤션과 대조된다.

변수 이름은 짧지만 의미가 있어야 한다. 변수 이름의 선택은 기억하기 쉽게 — 즉, 대충 보는 사람에게 그 사용 의도를 나타내도록 — 설계되어야 한다. 한 글자 변수 이름은 임시 "버려지는" 변수를 제외하고는 피해야 한다. 임시 변수의 일반적인 이름은 정수에 대해 i, j, k, m, n이고, 문자에 대해 c, d, e이다. int             i;
 char            c;
 float           myWidth; 상수 상수는 SCREAMING_SNAKE_CASE로 작성되어야 한다. 상수 이름에는 적절하다면 숫자도 포함될 수 있지만, 첫 글자는 숫자가 아니어야 한다. 
자바 컴파일러는 이러한 규칙을 강제하지 않지만, 이를 따르지 않으면 혼란과 오류가 발생할 수 있다. 예를 들어, widget.expand()와 Widget.expand()는 상당히 다른 동작을 암시한다. widget.expand()는 widget이라는 인스턴스의 expand() 메서드 호출을 의미하는 반면, Widget.expand()는 Widget 클래스의 정적 expand() 메서드 호출을 의미한다.

널리 사용되는 자바 코딩 스타일 중 하나는 클래스에 UpperCamelCase를 사용하고 인스턴스 및 메서드에 lowerCamelCase를 사용하도록 지시한다.
이러한 사용법을 인식하여 이클립스와 같은 일부 IDE는 카멜 표기법을 기반으로 하는 단축키를 구현한다. 예를 들어, 이클립스의 콘텐츠 지원 기능에서 카멜 표기법 단어의 대문자만 입력하고 콘텐츠 지원을 활성화하면 일치하는 클래스 또는 메서드 이름이 제안될 수 있다(예: "NPE"를 입력하고 콘텐츠 지원을 활성화하면 NullPointerException이 제안될 수 있다).

세 글자 이상의 두문자어는 대문자 대신 카멜 표기법을 사용한다(예: parseDBMXMLFromIPAddress 대신 parseDbmXmlFromIPAddress). 두 글자 이상으로 경계를 설정할 수도 있다(예: parseDbmXmlFromIpAddress).

 자바스크립트 

내장 자바스크립트 라이브러리는 자바와 동일한 명명 규칙을 사용한다. 자료형 및 생성자 함수는 어퍼 카멜 케이스(RegExp, TypeError, XMLHttpRequest, DOMObject)를 사용하고 메서드는 로어 카멜 케이스(getElementById, getElementsByTagNameNS, createCDATASection)를 사용한다. 일관성을 유지하기 위해 대부분의 자바스크립트 개발자는 이러한 규칙을 따른다.
참조: 더글라스 크록포드의 규칙

 리스프 
대부분의 리스프 방언에서 일반적인 관행은 with-open-file 및 make-hash-table과 같이 식별자의 단어를 대시로 구분하는 것이다. 동적 변수 이름은 관례적으로 별표로 시작하고 끝난다: *map-walls*. 상수 이름은 더하기 기호로 표시된다: +map-size+.Naming conventions on CLiki

 .NET 
마이크로소프트 .NET은 대부분의 식별자에 대해 UpperCamelCase를 권장하며, 이는 PascalCase로도 알려져 있다. (lowerCamelCase는 매개변수 및 변수에 권장되며) .NET 언어의 공유 규칙이다.Microsoft .NET Framework Capitalization Styles 마이크로소프트는 또한 유형 접두사 힌트(일명 헝가리안 표기법)를 사용하지 말 것을 권장한다..NET Framework Developer's Guide – General Naming Conventions 헝가리안 표기법 대신 기본 클래스 이름으로 이름을 끝내는 것이 권장된다. BtnLogin 대신 LoginButton.[Framework Design Guidelines, Krzysztof Cwalina, Brad Abrams Page 62]

 오브젝티브-C 
오브젝티브-C는 스몰토크에 뿌리를 둔 일반적인 코딩 스타일을 가지고 있다.

클래스, 프로토콜, 카테고리를 포함한 최상위 엔티티와 전역 변수 및 함수와 같은 오브젝티브-C 프로그램에서 사용되는 C 구조체는 NSString, UIAppDelegate, NSApp 또는 CGRectMake와 같이 짧은 모든 대문자 접두사로 네임스페이스를 나타내는 UpperCamelCase를 사용한다. 상수는 선택적으로 kCFBooleanTrue와 같이 소문자 "k"로 접두사를 붙일 수 있다.

객체의 인스턴스 변수는 밑줄이 앞에 붙은 lowerCamelCase를 사용한다(예: _delegate 및 _tableView).

메서드 이름은 인수를 구분하는 콜론으로 구분된 여러 lowerCamelCase 부분을 사용한다(예: application:didFinishLaunchingWithOptions:, stringWithFormat: 및 isRunning).

 파스칼, 모듈라-2 및 오베론 
비르트 언어인 파스칼, 모듈라-2 및 오베론은 일반적으로 프로그램, 모듈, 상수, 형식 및 프로시저에 Capitalized 또는 UpperCamelCase 식별자를 사용하고 수학 상수, 변수, 정식 매개변수 및 함수에 lowercase 또는 lowerCamelCase 식별자를 사용한다.Modula-2 Name Convention 일부 방언은 식별자에 밑줄과 달러 기호를 지원하지만, 스네이크 케이스 및 매크로 케이스는 외부 API 인터페이스 내에서 사용되는 것으로 제한될 가능성이 더 높다.

 펄 
펄은 관례를 위해 C의 유산을 따른다. 지역 범위 변수 및 서브루틴 이름은 접미사 밑줄과 함께 소문자이다. 비공개로 취급될 서브루틴 및 변수는 밑줄로 접두사가 붙는다. 패키지 변수는 대문자이다. 선언된 상수는 모두 대문자이다. 패키지 이름은 프라그마(예: strict 및 mro)를 제외하고 카멜 케이스이며, 프라그마는 소문자이다.

 PHP 
PHP 권장 사항은 PSR-1 (PHP 표준 권장 사항 1) 및 PSR-12에 포함되어 있다. PSR-1에 따르면, 클래스 이름은 PascalCase여야 하고, 클래스 상수는 MACRO_CASE여야 하며, 함수 및 메서드 이름은 camelCase여야 한다.

 파이썬 및 루비 
파이썬과 루비는 모두 클래스 이름에는 UpperCamelCase를, 상수에는 CAPITALIZED_WITH_UNDERSCORES를, 다른 이름에는 snake_case를 권장한다.

파이썬에서는 이름이 "비공개"로 의도된 경우 하나 또는 두 개의 밑줄이 앞에 붙는다. 비공개 변수는 파이썬에서 관례에 의해서만 강제된다. 파이썬 키워드와의 충돌을 방지하기 위해 이름 뒤에 밑줄을 붙일 수도 있다. 이중 밑줄을 접두사로 붙이면 네임 맹글링과 관련하여 클래스의 동작이 변경된다. 이중 밑줄로 접두사와 접미사를 붙이는 소위 파이썬의 "dunder"("double under") 메서드는 파이썬 객체에서 특별한 동작을 수행하는 "마법 이름"을 위해 예약되어 있다.Style Guide for Python Code PEP8

 R 
R에 대한 공식적인 스타일 가이드는 없지만, R 전문가 해들리 위컴(Hadley Wickham)의 tidyverse 스타일 가이드가 대부분의 사용자에게 표준을 제시한다.Style Guide for RCode  이 가이드는 파일, 변수, 함수 이름에 숫자, 소문자, 밑줄만 사용할 것을 권장한다(예: fit_models.R). 바이오컨덕터(Bioconductor) 스타일 가이드는 클래스 이름에는 UpperCamelCase를, 변수 및 함수 이름에는 lowerCamelCase를 권장한다.

선행 언어인 S와 S-PLUS는 변수 및 함수 이름에 밑줄을 허용하지 않고 대신 마침표를 구분 기호로 사용했다. 그 결과, R의 많은 기본 함수는 여전히 as.data.frame()와 같이 마침표를 구분 기호로 사용한다.

숨겨진 객체는 .hidden_object와 같이 점 접두사로 생성할 수 있다. 이러한 객체는 전역 환경에 나타나지 않는다. 점 접두사는 종종 패키지 개발자가 순전히 내부적이며 최종 사용자가 사용할 수 없는 함수에 사용한다. 이는 파이썬의 밑줄 접두사와 유사하다.

 라쿠 
라쿠는 펄과 거의 같은 규칙을 따르지만, 식별자 내에 중간에 하이픈 - 또는 아포스트로피 ' (또는 단일 따옴표)를 허용하며 (두 개를 연속해서는 안 됨), 그 뒤에 알파벳 문자가 와야 한다. 따라서 라쿠 프로그래머는 종종 식별자에 케밥 케이스를 사용한다. 예를 들어, fish-food 및 don't-do-that은 유효한 식별자이다.

 러스트 
러스트는 타입 별칭과 구조체, 트레이트, enum, enum 변형 이름에는 UpperCamelCase를, 상수나 정적 변수에는 SCREAMING_SNAKE_CASE를, 변수, 함수 및 구조체 멤버 이름에는 snake_case를 권장한다.

 스위프트 
스위프트는 각 개별 릴리스마다 명명 규칙을 변경해 왔다. 그러나 스위프트 3.0의 주요 업데이트로 변수 및 함수 선언 전반에 걸쳐 lowerCamelCase에 대한 명명 규칙이 안정화되었다. 상수는 일반적으로 enum 타입 또는 상수 매개변수로 정의되며 이 또한 동일한 방식으로 작성된다. 클래스 및 기타 객체 타입 선언은 UpperCamelCase이다.

스위프트 3.0부터는 모든 타사 API에 걸쳐 API 명명 및 선언 규칙을 표준화하기 위한 노력으로 언어에 대한 명확한 명명 지침이 마련되었다.

 같이 보기 
 :분류:명명 규칙
 체크스타일
 코딩 컨벤션
 정적 코드 분석 도구 목록
 이름공간
 시길 (컴퓨터 프로그래밍)
 구문 (프로그래밍 언어)

 각주 

 외부 링크 
 coding-guidelines.com에는 식별자 명명 문제의 비용/혜택 분석을 시도하기 위해 언어학과 심리학을 사용하는 pdf가 있다.


분류:소스 코드