C #의 Pascal-casing 메서드 이름의 철학 / 추론은 무엇입니까?

22

C #을 배우기 시작했습니다. Java, C ++ 및 Objective-C의 배경에서 온 C #의 Pascal- 케이싱 메소드 이름은 다소 독특하며 처음에는 익숙하지 않습니다. 이것에 대한 추론과 철학은 무엇입니까?

C # 속성 때문이라고 생각합니다. 메소드 이름이 인스턴스 변수와 정확히 동일 할 수있는 Objective-C와 달리 C #에서는 그렇지 않습니다. 속성을 가진 목표 중 하나는 (지원하는 대부분의 언어와 마찬가지로) 속성을 변수와 메소드와 구별 할 수 없게 만드는 것입니다. 따라서 C #에서 "int x"를 가질 수 있고 해당 속성이 X가됩니다. 속성과 메서드를 구분할 수 없도록하기 위해 필자가 추측 한 모든 메서드 이름도 대문자로 시작해야합니다. (이것은 내가 지금까지 C #에 대해 알고있는 것을 기반으로 한 가설입니다. 나는 여전히 배우고 있습니다). 이 호기심 많은 지침이 어떻게 생겼는지 알고 싶습니다.

(편집 : Pascal-casing은 PascalCase를 의미합니다 (기본적으로 camelCase이지만 대문자로 시작합니다). 메소드 이름은 일반적으로 대부분의 언어에서 소문자로 시작합니다)

c# programming-languages history naming-standards

— 야상곡
소스

어떤 가족의 모든 구성원이 자신의 집에있는 모든 벽에 이상한 휘장이 칠해져있는 것을 보았을 때 왜 그렇게 이상한 일을했는지 궁금하십니까?

— 녹턴

1

왜 파스칼 사건 이라고 생각 합니까?

— R. Martinho Fernandes

1

@Martinho Fernandes이 스타일의 표준 이름입니다. Google을 확인하십시오

— Andrey

1

@Nocturne-그렇습니다. 궁금합니다 :)

— Joel Etherton

1

"대부분의 언어에서 소문자로 시작하는 방법 이름"은 제 경험상 거짓입니다. 밑줄로 단어를 구분하거나 포함하지 않고 대문자로 시작하는 규칙은 공식 언어 지침에 반드시 필요한 것은 아니지만 매우 일반적입니다. 대부분의 언어 표준에는 공식 스타일 가이드가 하나도 없습니다. 대부분의 언어 (주로 오래된 언어)는 어쨌든 대소 문자를 무시하며 종종 눌리지 않는 것이 가장 혼란스러운 규칙이므로 동일한 혼동으로 취급되는 대소 문자가 다른 철자를 사용하지 않기 때문에 모든 경우에 소문자 규칙이 있습니다. .

— Steve314

27

맛의 문제입니다. 누군가는 한때 이름에 파스칼 스타일을 사용하기로 결정했고 표준이되었습니다.

나는 그것이라고 야생의 추측이 앤더스 헤 즐스 버그 델파이의 건축가, 파스칼의 후계자였다. 케이스 스타일은 C #에서와 동일합니다.

— 안드레이
소스

이것은 내 대답이 될 것입니다. : P

— DevSolo

@DevSolo 죄송합니다, 질문이 Stackoverflow에있을 때 답변을 입력하기 시작했습니다 :)

— Andrey

나는 뿌리가 고대 역사 속으로 더 깊이 들어가고 있다고 생각합니다. 아래 답변을 참조하십시오 :)

— davka

20

이유를 묻는다면 말의 입에서 나온 것입니다.

MSDN 블로그에서 Brad Abrams의 Pascal Casing 및 Camel Casing 관련 기사

프레임 워크의 초기 디자인에서 우리는 이름 지정 스타일에 대해 수백 시간 동안 토론했습니다. 이러한 논쟁을 촉진하기 위해 여러 용어를 만들었습니다. 디자인 팀의 핵심 멤버 인 Anders Heilsberg ( Turbo Pascal 의 최초 디자이너 )를 사용하여 Pascal 프로그래밍 언어로 대중화되는 케이싱 스타일로 Pascal Casing이라는 용어를 선택한 것은 당연합니다.

파스칼 케이싱 규칙은 각 단어의 첫 문자 (두 글자 이상의 머리 글자를 포함)를 대문자로 사용합니다.

다음은 설계 지침입니다. 클래스 라이브러리 개발자를위한 설계 지침

이 지침은 클래스 라이브러리 설계자가 다른 솔루션 간의 장단점을 이해하는 데 도움을주기위한 것입니다. 우수한 라이브러리 디자인이 이러한 디자인 지침을 위반해야하는 상황이있을 수 있습니다. 그러한 경우는 드 물어야하며, 결정에 확실한 근거를 제공하는 것이 중요합니다. 이 섹션에서는 .NET Framework의 유형에 대한 이름 지정 및 사용 지침과 일반적인 디자인 패턴 구현 지침을 제공합니다.

— 요게 쉬
소스

2

TurboPascal마이크로 소프트가 잊을 수있는 매우 편리한 Philip Kahn(일명 Borland) 의 아기이다 . 정치 ....

— davka

1

첫 번째 링크에 대한 의견은 훌륭합니다.

— jmq

7

철학에 대해 모르지만 파스칼 케이싱은 적어도 Win32 API 일 이후 Microsoft 플랫폼에서 일반적으로 보입니다.

— 네마냐 트리 푸노 비치
소스

8

그리고 나는 아직도 그것을 미워합니다.

— jmq

2

나는 그 뒤에 구체적인 철학이 있다고 생각하지 않습니다. 지침이 필요했고 그 지침에 영향을 줄 수있는 많은 점이있었습니다.

그들은 접두사 표기법을 없애고 싶었습니다 (헝가리어 읽기)
그들은 단지 그들의 이름을 읽음으로써 지역 / 개인 회원들과 공공 회원들이 구별되기를 원했습니다.
그들은 C # 코드가 Java 코드처럼 보이기를 원하지 않았습니다 (카멜 케이스를 많이 사용함)

— 디 사이클론
소스

이 명명 지침은 특히 C #이 아닌 .NET 프레임 워크를위한 것입니다. 대소 문자를 구분하지 않는 언어 인 VB.NET에서는 규칙이 동일하게 유지되지만 대 / 소문자를 구분하여 개인 구성원과 공용 구성원을 구별 할 수는 없습니다.

— R. Martinho Fernandes

@Martinho : 동의했습니다. 그러나 나는 여전히 그 이유 중 하나라고 생각합니다.

— decyclone

7

+1 : "C # 코드를 Java 코드처럼 보지 않기를 원했습니다. (낙타를 많이 사용합니다)"

— Giorgio

아이러니 한 것은 일부 사람들의 헝가리 표기법에 대한 증오에도 불구하고 Java 및 C #은 Apps 헝가리어 (또는 다른 명명 규칙)를 채택하여 가변 객체를 "소유"하는 참조 유형 필드를 구별하는 경우 실제로 훨씬 더 나은 언어 였을 것입니다. 따라서 변경 해서는 안되는 변경 가능 유형 인스턴스를 식별하는 인스턴스 등이 있습니다. 런타임이 이러한 차이를 신경 쓰지 않더라도 어떤 변수가 어떤 종류인지 알지 않고 효율적이고 정확한 코드를 작성하는 것은 불가능합니다.

— supercat

0

케이싱 뒤에 "철학"이 있다는 것은 잘 모르겠습니다. 멋지고 콤팩트하며 밑줄을 사용하지 않고 여러 단어로 쉽게 나타날 수 있습니다.

지난 수십 년 동안 많은 변형이있었습니다. 그것들은 매우 간결한 것부터 (C와 표준 C 라이브러리 참조) 각 단어를 구분하는 밑줄로 자세하게 표시했습니다. .NET 라이브러리 명명 규칙은 여전히 장황하지만 케이싱에 이르기까지 중간 정도의 타격을받는다고 생각합니다.

— 조나단 우드
소스

5

잊을 수없는 입술 스타일 이름 지정!

— R. Martinho Fernandes

@Martinho Fernandes는 실제로 c와 같은 언어와 관련하여 유효하지 않습니다.

— Andrey

예, Lisp는 공백을 고려합니다. (- var1 var2)

— Michael K

@Martinho Fernandes : 물론, 토큰을 분리하기 위해 공백을 사용해야합니다. 또한 COBOL-STYLE-NAMING이기도합니다.이 언어는 내가 가장 존경하고 가장 존경하는 언어에 공통입니다.

— David Thornley

0

C # 디자인은 Pascal의 최초 발명가 인 Niklaus Wirth 가 감독했습니다 . 연결을 보시겠습니까? ... :)

호기심 # 1 : 나는 .NET과 C # (예, 나는 선사 시대)의 발표와 C #에 Wirth의 이름을 붙임으로써 Microsoft가 얼마나 격렬한지를 기억합니다. 그러나 (C # 및 Wirth)의 Wikipedia 페이지는 이것을 언급하지 않습니다.

호기심 # 2 :이라고 불리지 만 언어 자체가 아니라 컴파일러에 PascalCase의해 대중화 TurboPascal되었습니다 Borland.

— 다 브카
소스

4

터보 파스칼은 Anders Hejlsberg가 편리하게 설계하고 제작했습니다 ...

— SWeko

3

Anders Hejlsberg는 IIRC 델파이의 수석 디자이너였으며 Turbo Pascal에서 많은 일을했지만 Turbo Pascal은 원래 그의 아기가 아니 었습니다 (Philip Kahns). Niklaus Wirth는 원래 파스칼을 발명하고 표준화를 거쳐 표준을 크게 무시했습니다. 또한 Wirth는 C #의 전체 수명 동안 은퇴했으며 그 전에 여러 후속 파스칼 언어 (가장 최근 Oberon 2)를 설계했기 때문에 그가 직접적으로 관여 한 것은 의심 스럽다. 마이크로 소프트는 헤 즐스 버그를 선포 한 것에 대해 큰 소리로 말했다. Turbo Pascal은 처음부터 볼랜드 제품이었습니다.

— Steve314

다운 그레이드는 신경 쓰지 않습니다. StackOverflow에 대한 충분한 정보가 있지만 그 이유가 궁금합니다.

— davka