왜 우리는 Enum, Abstract 클래스 및 Structs를 접두어로 사용하지 않습니까?

C # 커뮤니티는 "I"접두어를 아주 보편적으로 사용하여 가장 경험이없는 프로그래머조차도 사용하는 인터페이스를 나타냅니다.

그렇다면 왜 열거 형, 추상 클래스 또는 구조체 (각각 "E", "A"및 "S")를 접두어로 사용하지 않습니까?

예를 들어, 모든 추상 클래스에 "A"를 표시 한 경우 유추 할 수 있지만 즉시 명백하지 않은 해당 유형에 대한 유용한 정보를 제공합니다.

나는이 변화를 옹호하지 않고 단지 왜 우리가 이런 식으로 일을하지 않는지를 이해하려고 노력하고 있습니다.

이 스레드 는 "I"접두사를 사용하는 이유에 대한 답변이지만 다른 접두사를 사용 하지 않는 이유에 대해서는 답변 하지 않습니다 .

c# .net coding-standards source-code

— 스티븐
소스

나는 중복 투표에 투표하지만 대답은 SO stackoverflow.com/questions/111933/…에 있습니다.

— Euphoric

@ 유포 릭 :이 질문은 훨씬 더 구체적입니다.

— reinierpost

의 가능한 중복 어떻게 헝가리어 표기법을 사용하지의 이익인가?

— gnat

IMO 열거 형은 피해야하고 (공개 정적 읽기 전용 멤버 (열거 형 패턴으로 대체)) 추상 클래스에는 "기본"접미사 가 있어야 하고 구조체 는 명명 규칙으로 소문자 가 있어야 하지만 .NET에서는 그렇게하지 않습니다. 구조체를 소문자로 만들면 혼란스럽지 않습니다. 일관되지 않습니다.

— Dave Cousineau

psuedo 열거 형을 만들기 위해 열거 형을 사용하지 않는 이유는 무엇입니까?

— Stephen

답변:

인터페이스의 명명 규칙의 요점은 클래스가 구현하는 인터페이스를 무엇을 호출해야하는지에 대한 빠르고 확실한 결정을 제공하는 것입니다. 가 Frobnicator있지만 분리 또는 다른 이유에 대한 인터페이스를 선언 해야하는 경우 호출 결정 IFrobnicator에는 의식적인 생각 이 필요하지 않으며 이것이 좋습니다.

같은 문제는 당신이 지명 한 다른 구조에는 적용되지 않습니다. 열거 형과 구조체는 유용하지만 이름 자체 외에도 짧고 투명하며 명백히 관련된 두 번째 이름 을 찾을 필요는 없습니다 . 따라서 열거 형이나 구조체의 이름에 'E'를 두 드려야 할 압력이 없습니다.

(추상 클래스는 인터페이스와 다소 유사합니다. 두 번째 구체적인 클래스를 제공해야 무언가를 수행 할 수 있으므로 'A'로 시작하는 규칙을 얻었을 수도 있지만 어떤 이유로 든 그렇지 않습니다. 나는 추측 할 수있다. 나는 특히 '좁은 글자'가 그것과 관련이있을 수 있다고 생각한다.)

— 킬리안 포스
소스

+1 이것이 내가 쓴 답변입니다. 그 추상 클래스가 이미 추상 클래스의 이름은 완벽하게 cromulent 명명 규칙을 가지고 있지만 내가 지적 거라고 AnimalBase별개의 맛은 AnimalGiraffe, AnimalLion등

— 이진 걱정하는

그것은 많은 자바 인터페이스를 사용하지 않는 언급 할 가치가있을 수 있습니다 'I'와 같은 List, 아주 기술적으로 명명 된 이후 ArrayList및 LinkedList구현의 이름이다. (C # IList은 인터페이스와 List배열 목록을 가지고 있다고 생각 합니다)

— Katana314

Microsoft가 "mutable"구조 유형의 변수 에 Point p = myPoints[3]; p.X += 3;영향을 미치는지 여부에 대한 혼동을 피하기 위해 특정 접두사를 지정하도록 권장했을 때 도움이되었을 지 궁금합니다 myPoints[3].X. 회고 적으로, C # var->field을 클래스 필드 액세스 및 var.field구조체 필드 액세스에 사용하는 것이 좋았지 만 분명히 그렇지 않습니다. 여전히, 그것들을 구별하는 한 눈에 볼 수있는 수단이 도움이 될 것 같습니다.

— supercat

나는 그것이 많이 사용되지 않는다고 생각합니다.

대부분의 경우 열거 형이거나 추상적 인 클래스 또는 구조체 인 경우 많은 관계가 없습니다.
그것이 mater라면 아마 사용법에서 그것을 볼 수 있고 그렇지 않으면 꽤 빨리 알아낼 수 있습니다.
열거 형, 추상 클래스 또는 구조체로 변경하면 이름을 바꿔야합니다.
컨벤션을 모르는 사람들에게는 순수한 소음입니다.
사람들은 헝가리어 표기법을 사용하지 말라고 배웠기 때문에 전체 아이디어를 무시할 수 있습니다. Apps Hungarian과 Systems Hungarian을 구분하지 않고 Hungarion 표기법을 사용해서는 안된다고 말하는 사람들이 있습니다. 이 SO 질문 에서 좋은 토론을 찾을 수 있습니다 . 첫 번째 답변뿐만 아니라 흥미로운 답변과 의견이 있습니다. 같은 질문에서 Joel Spolsky 의이 기사 가 나옵니다 ( "I 'm Hungary"단락으로 스크롤)

간단히 말해서 : 일반적으로 부가 가치는 비용에 합산되지 않습니다.

마지막 글 머리 기호와 일부 해석에서 결론을 내릴 수 있습니다. 시스템 헝가리어 (접두사 유형)가 잘못되어 사용해서는 안됩니다. 앱 헝가리어 (접두사 종류)에서 사용합니다.

귀하의 질문을 다시 받아 들여 귀하의 제안 된 표기법은 Apps Hungarian의 한 형태라고 생각합니다. 추가 가치가 비용에 추가되고 코드 기반으로 일관되게 구현한다고 생각하면 괜찮습니다. 그러나 프로젝트별로 고려해야하기 때문에 일반적인 규칙이되어서는 안됩니다.

사람들은 인터페이스가 더 자주 짝짓기되어 인터페이스의 일반적인 규칙이 된 이유를 알았습니다.

— KeesDijk
소스

-1

단지 (적절하게 적용 가능한) 생각 :

구체적인 클래스가 아닌 '인터페이스 코딩'이라는 경향이 있습니다. "Nowadays"는 인터페이스에 문자 'I'가 아닌 'C'로 시작하는 것과 같이 클래스에 대한 명명 규칙을 갖는 것이 거의 유리합니다.

방금 모든 인터페이스가 실제로 모델이라는 Java 프로젝트를 종료했습니다. 그렇습니다. 인터페이스 이름 규칙은 이름을 'Model'로 끝내는 것이 었습니다. 그런 다음 'DataTransferObject / DTO'의 일종으로 인터페이스를 :

public interface SomethingModel{
}

public class Something implements SomethingModel{
    //lets not line up braces and make it hard to read
    //at least it saves one line
}

반면 C #에서는

public interface ISomething{}

public class SomethingModel : ISomething
{
   //i can read this
}

뇌를 바꿔서 상처를 입히지 만 인터페이스에 대한 프로그래밍 용어로 생각하는 것이 어떻게 도움이되는지 볼 수 있습니다.

— 저드슨
소스