내 코드 및 데이터베이스 필드 이름 등에서 camelCase을 사용하지만 끝에는 Id의 필드가 있으므로 항상 읽기가 어려워집니다. 예를 들어, itemId, teacherId, unitId 등이 있습니다.이 경우 나는 가독성을 높이기 위해 규칙을 위반하고 itemID, teacherID, or unitID을 작성하는 것을 고려합니다.ID, ID 또는 ID?
무엇을하고이 문제를 다루는 일반적인 최선의 방법은 무엇입니까?
나는 기분이 좋아. 일반적으로 모범 사례는 가독성과 일부 추상 표준 준수를 잘못 판단하는 것입니다.
일관성을 유지하십시오.
나는 camelcase도 사용합니다. 이름이 Id로 끝나는 경우에도 사용합니다.
id
주관적인 질문에 대한 나의 주관적 대답입니다.
나는 이것을 CW로 표시했다.
이드의 문제는 내가 어떻게 비 (非) 자본과 비슷하게 생겼는지입니다. 따라서 unitId는 읽기에는 매우 모호합니다. –
이 글꼴은 비슷합니다. monospaced 글꼴을 사용하는 동안 (내가 어디에서나 코드를 사용하려고 시도합니다) 그렇지 않습니다. –
또는 소문자 l. 고정 폭 글꼴의 경우에도 문제가있을 수 있습니다. –
나는 우리 회사에서 ID를 사용하는 것을 선호하며 ID는 ID가있는 ID입니다. 읽을 때 더 쉽게 ID를 사용하는 것이 문제라고 생각하지 않습니다. 컴파일러는 상관하지 않습니다 :) 내 스키마 ID 열에 동일한 규칙을 사용합니다.
가독성이 가장 중요하다고 생각하며, 읽기가 훨씬 쉬워지면 컨벤션을 재정의해야합니다. 나는 우리 프로그래머가 컨벤션 및 프로토콜을 깨뜨리기를 싫어하기 때문에 그것을 쉽게 읽을 수 없다면, 단점은 총/컨벤션을 고수하는 전문가보다 중요하다고 생각한다.
ID와 동일합니다. Microsoft가 권장하는 명명 규칙은 권장되는 방법이며 코드 분석으로 컴파일하면이를 지원할 것임을 나타냅니다. ID가 각각 I와 D로 시작하는 두 단어로되어 있고 실제로 소문자로 시작하지만 매개 변수에서 이름을 사용하지 않는 경우 ID를 사용합니다.
ID는 "Identifying Digits"의 약자입니다. 무엇이든 두문자어를 만들 수 있습니다. ;) –
동의 함. 모든 사소한 프로젝트는 "ID"대신 "Id"를 제안하는 코드 분석 (FxCop)을 사용해야합니다. –
나는 OP가 Microsoft를 언급했다고 생각하지 않습니다. –
은 프로그램 전체에서 일관성이있는 한 중요하지 않습니다..
내가 말했듯이 나는 "Id"와 함께 갈 것입니다.
나는 두 진술에 모두 동의하고 일관성 있고 'ID'와 함께하기 때문에 ... 404 –
다음은 내가하는 일의 샘플입니다.
id
userId
getUserId
키가 일관되고 있습니다.
다른 사람들이 몇 명을봤을 때 CW가 추가되었습니다. –
모든 멋진 애들이하고있어! –
@Daniel 그들은 확실히 :) –
나는 모든 테이블 이름에서 밑줄을 사용하므로 user_id입니다. ID가 독립형 인 경우에도 모두 소문자입니다.
다른 언어의 가이드 라인이 다릅니다. .NET의 경우 Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries을 읽을 수 있습니다. Java의 경우 Code Conventions for the Java Programming Language을 읽을 수 있습니다.
Id는 머리 글자가 아닌 약어이므로 "Id"입니다. UI는 머리 글자이며 머리 글자 어는 짧은 글자로 대문자로 표기됩니다 : "UI".
여기에 최고의 대답; 아무도 이것을 upvoted 놀랐어요. +1 : – bryan
FWIW, 일부에서는 (.NET Framework 설계 지침 에서처럼) 두 글자의 약어는 완전히 대문자로 표기하고, 더 긴 약어는 일반 단어로 대문자로 표기합니다. 예 : DeferIO 및 XmlReader. 그것은 합리적이고 읽기 쉬운 방법으로 솔기가.니다. 하지만 이드는 여전히 이드이다. :) –
또한 FWIW ID는 사전에 따른 공식적인 약어입니다. 나는 당신이 이드를한다면 Ui와 Url을해야한다고 제안 할 것이다. – slifty
나는 실제로 "ID"를 선호합니다. 그러나 모두가 말했듯이 일관성이 가장 중요합니다.Machine SUIF에서 스티브
"ID"를 사용하면 일관성이 깨지지 만 읽기 쉽습니다. – awaisj
예, 더 읽기 쉽기 때문에 사용하고 있습니다. 하지만 항상 "ID"(예 : "userID", "commentID")를 사용하는 경우 일관성이 깨지는 이유는 무엇입니까? –
그는 코드의 나머지 부분이 camalCase이고 ID가 유일한 것임을 의미 할 수도 있습니다. –
, 마이크 스미스와 글렌 홀로 웨이 은 엄격하게는 대문자가 새로운 단어를 표시하는 경우 규칙을 적용합니다. 따라서 CPS는 약어로 transformToCps이고 transformToCPS이 아닙니다. 나는 장기적으로 그들의 방법이 우리가 ID에서 한 것보다 잘 작동한다는 것을 발견했습니다. 우리는 보통 ID와 CPS와 같은 경우에 대문자를 사용했습니다.
나는 여기에서 투표 할 것이지만 나는 상관하지 않는다!
분명히 id입니다. 깊은 곳에서 아이디어!
FxCop/Code Analysis는 ID가 잘못된 약어로 표시되므로 규칙을 사용하지 않으려면 해당 ID를 준수하고 사용해야합니다. 그러나 다시 한 번 말하지만, 이것은 다른 사람들이 지적한 바와 같이 당신이 일관성있는 한 실제로는 중요하지 않습니다.
자신의 프로그램 내에서 일관성을 유지하는 한 편안합니다. (팀에서 일하는 경우 팀 규칙을 따르거나 일부를 설정해야합니다.)
언급되지 않은 한 가지 점은 올바른 글꼴을 얻는 것이 중요하다는 것입니다. 즉 프로그램의 가독성에 경이를 할 것입니다 그리고 국제 대회 문제는 일부 글꼴 문제 일 수 있었다 : 당신은 쉽게 LD에서 아이디을 구별 할 수없는 경우
(Id and ld), 당신은 글꼴 아마도 글꼴을 변경하려면해야 크기도. 개인적으로 Consolas를 좋아합니다.
나는 가장 중요한 것이 일관성 있다는 다른 답변에 동의합니다.
특정 코드베이스에 대해 확립 된 표준이 없다면 언어 또는 플랫폼에서 설정 한 규칙을 따라야합니다. 자바에서는, 약어 및 기타 대문자 단어 식별자 uncapitalized 있습니다
목표 - C에서id
url
getId()
setUrlParameters()
, 그 반대입니다. 당신은 소문자 "ID"또는 "URL"변수가있을 수 있습니다,하지만 당신은 또한 다음과 같은 클래스가 :
setURLParameters:
C에서 대문자로 된 상수는 매우보기 흉하게 보입니다. PHP는 또한 이들 중 일부를 계승했습니다. –
그것은이다 :
의 Obj-C에 따라서NSURL
NSURLRequest
내가 같은 메소드 이름을 선택할 것을 이드는 "아이디, 자아, 초자아 같은"이드가 아니라 ID라고 발음했다. 그건 내 투표 야. 두문자어가 아닌 약어라는 사실은 발음되는 방식 때문에 부적절합니다. 두문자어로 발음되기 때문에 타이핑도 가능합니다. 오, 낙타의 경우는 컴퓨팅 역사상 최악의 아이디어입니다. :)
"Id"는 모호합니다. 그것은 인간 정신의 "자아"/ "초자아"모델의 일부입니까? 아마 당신은 아마 "Identity"나 "Identification"이나 "Identifier"와 같은 단어를 생략하려고 시도했을 것입니다.
의미를 결정하여 모호성 (및 케이스 질문)을 제거한 다음 을으로 축약하지 마십시오.
데이터베이스 열과 개체 속성의 ID.매개 변수의 ID :
this.ID == id
CW 꿈 마지막 몇 초. – OscarRyz
c'est la vie 등등 ;-) – Shog9