변수 이름이 ID 또는 ID 여야합니까? [닫은]

126

이것은 약간의 장난이지만 일부 사람들은 다음 Id과 같이 사용하는 것을 보았습니다 .

private int userId;
public int getUserId();

다른 사람들은 다음을 사용합니다.

private int userID;
public int getUserID();

이 중 하나가 다른 것보다 더 나은 이름입니까? 왜? 나는 이것이 대규모 프로젝트에서 매우 일관되지 않은 것을 보았습니다. 내가 대부분의 사람들에게 익숙한 표준을 설정한다면? 기존의 표준은 무엇입니까?

coding-style naming variables

— 아담
소스

40

일관성은 가장 중요한 것입니다. 낙타 사건이거나 밑줄 또는 기타가 아닙니다. 일관성을 유지하십시오.

38

언어의 XML API를보고 어떻게 작동하는지 확인하십시오. Java는 클래스를 좋아 SAXParser하고 DOMException.NET은 클래스를 좋아 XmlDocument합니다. 이를 바탕으로 Java에서는 "ID", C #에서는 "Id"라고합니다.

— luiscubal

1

그러나 대문자 식별자는 일반적으로 Java에서 정적 필드에 사용되므로 기본 필드의 "ID"이름이 가장 적합하지 않습니다. 그리고 일관성이 있습니다 ...

— Danubian Sailor

8

당신은 변수의 이름을시겠습니까 EGO및 SuperEGO? 나는 그렇게 생각하지 않았다. ;)

— kojiro 2013

4

뭐?! 일관성? 분노의 전쟁은 어디에 있습니까?! 그로 인해 나는 신성한 낙타 사건의 구문 화염을 지키는 자임을 지명하고,이를 위해 모든 약어로 그것을 행하는 것이 멍청한 자임을 선언한다. 또한 지루하고 이상한 일을하는 고양이가 없다면 화장지 롤을 윗면에서 올리는 것이 옳습니다. 고양이 소유자. 나는 왜 그것에 대해 판결을 내려야하는지 모른다. 화장실 롤 방향의 성스러운 불꽃을 지키는 밥은 바쁘다.

— Erik Reppen

56

이러한 경우에 따라야 할 가장 중요한 규칙은 일관성입니다. 다른 사람과 마찬가지로하십시오.

예를 들어, 언어의 XML API를보고 어떻게 작동하는지 확인하십시오.

같은 자바 이름 클래스 SAXParser를 하고 예외 : DOMException 같은 .NET 이름 클래스 을 XmlDocument .

이를 바탕으로 Java에서는 "ID", C #에서는 "Id"라고합니다.

그러나 Java EE 6에는 이름이 지정된 주석이 있습니다 @Id( documentation 참조 ). Java는 "Id"를 단순한 단어로 간주합니다.

— luiscubal
소스

@Id는 변수 이름이 아닌 주석 클래스 이름을 가리 킵니다. 잘못된 예입니다.

— jwenting

3

SAXParser는 SimpleAPIforXMLParser (또는 ExtensibleMarkupLanguageParser의 SimpleAPIforXMLParser) 일 수도 있습니다. 각 대문자는 단어의 시작입니다. 따라서 자바에서도 "Id"여야합니다.

— user470365

2

@jwenting 문제는 "id"가 단어로 간주되는지 두 단어로 간주되는지 알아내는 것입니다. @Id이 단어는 한 단어이므로 변수 이름은 "id"입니다.

— luiscubal

아니요. SAX는 약어 인 반면 ID는 그렇지 않습니다.

— nalply

8

IdC # (및 일반적으로 .NET)에서 사용하는 것이 옳지 만 다른 이유가 있습니다. 규칙은 2 글자 머리 글자 (예 :)의 모든 문자를 IPAddress대문자로하고 더 긴 두문자어의 첫 문자 만 대문자로 표시합니다 (예 : XmlDocument귀하가 제시 한 예 ). 그러나 Id과 Ok특별히 언급이 규칙에 예외가 있습니다. 전체 내용 Capitalization Rules for Acronyms은 Capitalization Conventions기사 섹션을 참조하십시오. 그러나 마이크로 소프트조차도 그 규칙을 어 DbConnectionDBNull

— 기고있다

110

일관성은 왕입니다. 하나 또는 다른 하나를 선택하지만 어디서나 일관되게 수행하십시오.

즉, 낙타 케이스를 위반하지 않기 때문에 첫 번째 변형을 선호합니다 (따라서 하나의 스타일이 아니라 두 가지 스타일 규칙을 기억해야 함).

이 때문에 때때로 두 개의 대문자가 사용 되지만 ID는 실제로 ID 인증의 한 형태 일뿐입니다.

— 로버트 하비
소스

18

컴퓨터 프로그램이 내 ID에 액세스하려고하면 마음에 들지 않습니다.

— Blrfl

1

userIdOfSender

— Sean McSomething

19

@SeanMcSomething : Ick. SenderUserId

— Robert Harvey

5

"ID"가 혼동이 발생하는 위치를 확인할 수있는 선호되는 방법이라는 데 동의하지만, 일상 대화에서 "ID를 볼 수 있습니까?"와 같이 실제로 약어라고합니다.

— 내부 서버 오류

3

낙타의 경우 다른 머리 글자를보십시오. SOAPProtocol이 아닌 SoapProtocol이 있습니다. ID는 신분 증명서의 약자이므로 낙타의 경우 예외적으로 처리해야하는 이유를 모르겠습니다. 즉, 내 프로그램에서 userId 및 userID가 일관되게 사용되는 것보다 일관되게 사용되는 userID를 선호합니다.

— Neil

76

TL; DR : .NET 클래스 라이브러리와 관련하여 Id를 사용하는 것이 좋습니다. 이것은 허용 / 권장되는 약어의 드문 예이므로 약간 반 직관적입니다 (약어는 일반적으로 찌그러짐).

C # 또는 .NET 클래스 라이브러리 규칙에 대해 이야기하는 경우 Microsoft는 상당히 잘 정의 된 명명 지침을 사용할 수 있습니다. 다양한 문제에 대한 많은 설명과 함께 잘 알고 있습니다. 실제로 모든 개발자는 전체 디자인 지침 섹션 을 읽는 데 시간이 걸립니다 .

그것이 올 때 약어 두 글자 약어를 들어, 당신은 그 (것)들에게 (파스칼 케이스 적용) 대문자를 유지하는 경향이있다, 그래서 예를 들면 : 엄지 손가락의 규칙은 IOStream클래스의 이름 일 수 있습니다. 더 긴 머리 글자의 경우 나머지 머리 글자 (예 : XmlDocument또는)를 소문자로 사용합니다 HtmlParser. 이것은 실제로 가장 모호하지 않은 규칙입니다 (두 글자의 두문자어를 묶지 않는 한 한 단어가 끝나고 다음 단어가 시작되는 위치에 대한 혼동이 없으며).

그렇다면 ID입니까, 아니면 ID입니까? 글쎄, 마이크로 소프트에 따르면, 당신의 생각과 다를 수도 있습니다.

약어는 다를 약어 약어가 하나의 단어를 단축하는 것이있다. 예를 들어, ID 는 identifier 의 약어입니다 . 일반적으로 라이브러리 이름은 약어를 사용하지 않아야합니다.

식별자에 사용할 수있는 두 약어는 ID와 OK입니다. Pascal-cased identifiers에는 Id와 Ok로 표시되어야합니다. 낙타로 구분 된 식별자에서 첫 번째 단어로 사용될 경우 각각 id와 ok로 표시되어야합니다.

실제로이 구분이 언제 지침에 나타나기 시작했는지는 확실하지 않지만 몇 년 전 (약 3.0 / 3.5) 클래스 라이브러리의 일반적인 명명 추세는 ID에서 ID로 바뀌 었습니다.

— 다니엘 B
소스

1

이것이 내가 일반적으로 따르는 지침입니다. id는 약어가 아닌 약어이므로 항상 'Id'를 사용하는 것을 선호합니다.

— Toby

나는 ID becuase를 사용하고 컨벤션을 깨뜨리고 독창적 인 것으로 눈에 : 다. 나는 그 아이러니를 좋아한다. :)

— RhysW

나는 마이크로 소프트가 틀렸다고 생각한다. ID는 신원 문서의 초기이며, 신원은 짧지 않습니다. (정말로 약어는 발음 할 수 있습니다.)

— Tom Hawtin-tackline

@ TomHawtin-tackline 상황에 따라 다르다고 생각하지만 흥미로운 점을 지적합니다. Person 객체의 IDNumber 속성과 같은 것이 의미가 있지만 VehicleId가 "Vehicle Identity Document"대 "Vehicle Identifier"로 읽히겠습니까? 프로그래밍 컨텍스트에서 identifier는 인스턴스를 고유하게 식별하는 모든 것에 대한 일반적인 단어이며 여기서 더 적용 가능하다고 주장합니다.

— Daniel B

@DanielB 컴퓨터 언어, 심지어 SQL에서도 "식별자"는 일반적으로 열 이름과 같은 이름을 나타냅니다. 일반적으로 "ident"로 축약됩니다. 차량은 흥미로운 VIN 체계 (차량 식별 번호)가 있기 때문에 흥미로운 예입니다. 일반적인 프로그래밍 컨텍스트에서 엔터티에 대한 "문서"는 숫자입니다 (피할 수없는 기능 일 수도 있음).

— Tom Hawtin-tackline

15

일부 코딩 규칙 문서에서 아주 좋은 설명을 읽었습니다. 낙타 표기법은 항상 단어 경계를 구분하기 쉽기 때문에 (비교, 약어 및 약어에 사용되어야 XmlIdWriter에 XMLIDWriter).

— 길든
소스

12

단어 경계를 구별하기위한 더 나은 아이디어가 있습니다 : 실제 단어 경계! xml_id_writer.

— Kaz

4

@Kaz 음, 어! 그러나 CamelCase는 전통적으로 일부 언어에서 사용되며 이러한 상황에서 밑줄을 사용하기에는 다소 부족합니다. 앞서 언급했듯이 일관성은 왕입니다.

— 길든

1

일부 언어의 핵심 라이브러리가 사용하기 때문에 CamelCase를 사용하는 것은 일관성이 아니라 적합성입니다.

— Kaz

3

@Kaz : 코드 컨벤션보다 상점에서 싸울 전투가 더 큽니다.

— Robert Harvey

2

JavaScript의 기본 함수에서 볼 수 있듯이 getElementById (); Camel 케이스로 작성된 ID ...

밑줄과 함께 사용하는 경우 'id'를 사용하십시오. 예 : user_id

밑줄없이 var의 이름을 지정하는 경우 'Id'를 사용하여 다른 단어를 구별하십시오. 예 : userId

단일 단어 변수 인 경우 완전한 소문자 여야합니다. 여러 단어 var 인 경우 낮은 Camel 대소 문자를 사용하십시오. 예 : thisIsExample

그러나 일반적으로 상수를 정의하기 위해 모든 대문자를 사용하기 때문에 CAPS에서는 'ID'를 모두 권장하지 않습니다.

— 수크 릿 굽타
소스

세 번째 단락에서 예가 텍스트와 일치하지 않는 것 같습니까?

— ruakh

@ruakh thanx .. 정류 ..

— Gupta

0

먼저 약어를 피하십시오.

둘째, 약어가 매우 잘 알려진 경우 낙타 케이스를 사용하는 것이 좋습니다.

그 의미를 고려할 필요가 없기 때문입니다. 그냥 평범한 단어로 취급

— 임성 국
소스