C # 개발자가 줄 바꿈을 여는 이유는 무엇입니까? [닫은]


44

지난 몇 년 동안 대부분 C # 및 SQL을 주로 사용했습니다. 그 시간 동안 내가 함께 일한 모든 프로그래머는 새로운 행에 함수 또는 제어 흐름 문의 여는 중괄호를 배치하는 습관을 가졌습니다. 그래서 ...

public void MyFunction(string myArgument)
{
     //do stuff
}

if(myBoolean == true)
{
    //do something
}
else
{
    //do something else
}

나는 이것이 특히 if / else 문장에서 공간 낭비가 얼마나 많은지에 항상 충격을 받았다. 그리고 C #의 이후 버전에는 다음과 같은 대안이 존재한다는 것을 알고 있습니다.

if(myBoolean == true)
    //do something on one line of code

그러나 거의 아무도 그것을 사용하지 않았습니다. 모든 사람들은 줄 바꿈에 중괄호를 사용했습니다.

그런 다음 오랫동안 부재 한 후에 JavaScript를 다시 시작했습니다. 내 기억에 JavaScript 개발자는 똑같은 중괄호 줄 바꿈 작업을 수행했지만 모든 새롭고 멋진 라이브러리와 물건을 사용하여 대부분의 개발자는 선언 뒤에 여는 중괄호를 넣었습니다.

function MyJavaScriptFunction() {
    //do something
}

클로저와 함수 포인터를 사용하는 것이 JavaScript에서 널리 사용되기 때문에 많은 공간을 절약하고 일을 더 읽기 쉽게하기 때문에이 점에서 의미가 있습니다. 그래서 C #에서 왜 그렇게 보이지 않는지 궁금했습니다. 실제로 Visual Studio 2013에서 위의 구성을 시도하면 실제로 여는 괄호를 새 줄에 배치하여 재구성합니다.

이제 코드 검토 SE 에서이 질문을 보았습니다. https://codereview.stackexchange.com/questions/48035/questions-responses-let-me-tell-you-about-you Java에서 내가 너무 익숙하지 않은 언어, 선언 직후에 현대적인 JavaScript 방식으로 중괄호를 여는 것은 까다로운 것으로 간주됩니다.

C #은 원래 Java를 기반으로 모델링되었으며 동일한 기본 코딩 표준을 많이 유지한다는 것을 항상 알고있었습니다. 그러나이 경우에는 그렇지 않습니다. 그래서 나는 그럴만한 이유가 있어야한다고 생각합니다. 그 이유는 무엇입니까? C # 개발자 (및 Visual Studio)가 새 줄에 중괄호를 여는 이유는 무엇입니까?


30
컨벤션은 간단합니다.
Oded

19
Visual Studio는 아무것도 시행하지 않으며 코드 스타일을 구성 할 수 있습니다. 뭔가 기본 할 필요가있다. "더 나은"기본값은 가장 높은 차수입니다.
Phoshi

23
줄 끝의 괄호는 고대 K & R C 표준입니다. Kernighan과 Ritchie는 컴퓨터 디스플레이에 25 줄 (헤더 및 상태 줄을 추가하면 23 줄) 만있을 때 C 언어를 발명했습니다. 더 이상은 그렇지 않습니다. 중요한 것은 프로젝트 전체의 일관성입니다. 있습니다 자신의 줄에 중괄호 (사실, 코드와 같은 수준으로 들여 쓰기) 보여주는 코드 향상 과학적 연구도 이해를 사람들이 미학의 생각 생각에도 불구하고가.
Craig

10
C #은 조건부 이후에 한 줄의 코드를 평가하는 것을 항상 지원했습니다. 사실, 지금까지는 이것이 유일한 일입니다. 분기 식 다음에 코드를 중괄호 안에 넣으면 해당 명령이 이동하게됩니다 (컴파일러는 jmp 명령을 사용하여 범위를 만듭니다). C ++, Java, C # 및 JavaScript는 대부분 기본적으로 동일한 기본 구문 분석 규칙을 사용하여 C를 기반으로합니다. 따라서 C #은 "Java 기반"이 아닙니다.
Craig

10
참고로, if(myBoolean == true)나에게는 거의 이해가되지 않습니다. 우리는 잠시 동안하지, 그것을있는 동안 if ((myBoolean == true) == true)?? 이것으로 if (myBoolean)충분합니다. 미안해 내 애완 동물 친구 야
Konrad Morawski

답변:


67

마지막 줄은 Brian Kernighan과 Dennis Ritchie의 저서 The C Programming Language 의 고대 K & R C 표준으로, UNIX 운영 체제와 C 프로그래밍 언어를 공동 발명 한 후 1978 년에 출판되었습니다. AT & T에서 Ritchie가 주로 설계했습니다.

예전에는 "하나의 진정한 버팀대 스타일"에 대한 화염 전쟁이있었습니다.

Ritchie는 C 언어를 발명했으며 Kernighan은 컴퓨터 디스플레이에 몇 줄의 텍스트 만 표시했을 때 첫 번째 자습서를 작성했습니다. 실제로 UNICS (이후의 UNIX) 개발은 사용자 인터페이스에 타자기, 프린터 및 종이 테이프를 사용하는 DEC PDP-7에서 시작되었습니다. UNIX와 C는 24 줄 텍스트 터미널로 PDP-11에서 완성되었습니다. 따라서 수직 공간은 실제로 프리미엄이었습니다. 오늘날 우리 모두 약간 더 나은 디스플레이와 고해상도 프린터를 가지고 있습니다. 내 말은, 난 당신에 대해 모르겠지만, 지금 내 앞에 3 개의 24 "1080p 디스플레이가 있습니다. :-)

또한, 그 작은 책인 C 프로그래밍 언어의 많은 부분 이 코드 샘플로, 줄 대신에 줄 끝에 괄호를 두는 것으로 인쇄에 상당한 비용이 절약되었다고합니다.

정말로 중요한 것은 프로젝트 전체 또는 최소한 주어진 소스 코드 파일 내에서의 일관성 입니다.

있습니다 자신의 줄에 중괄호 (사실, 코드와 같은 수준으로 들여 쓰기) 것을 보여주는 사람들이 미학의 생각 생각에도 불구하고 코드의 이해를 향상 과학적 연구도. 시각적으로 본능적으로 어떤 상황에서 어떤 코드가 실행되는지 독자에게 명확하게 보여줍니다.

if( true )
    {
    // do some stuff
    }

그런데 C #은 항상 분기 식 이후에 단일 명령 평가를 지원했습니다. 사실, 지금까지는 이것이 유일한 일입니다. 분기 식 다음에 코드를 중괄호로 묶으면 명령 하나만 이동하게됩니다 (컴파일러는 jmp 명령어를 사용하여 범위를 만듭니다). C ++, Java, C # 및 JavaScript는 대부분 기본적으로 동일한 기본 구문 분석 규칙을 사용하여 C를 기반으로합니다. 따라서 C #은 "Java 기반"이 아닙니다.

요약하면,이 종교 / 불꽃 전쟁 문제의 비트. 그러나 블록으로 코드를 배열하면 인간의 이해력이 향상된다는 것을 분명히하는 연구 가 있습니다 . 컴파일러는 덜 신경 쓰지 못했습니다. 그러나 이것은 또한 중괄호없이 분기 뒤에 코드 줄을 넣지 않는 이유와 관련이 있습니다. 나 또는 다른 프로그래머가 나중에 다른 코드 줄을 때리고 너무 늦지 않을 것이라는 사실에 너무 빠릅니다. 직전 또는 직후 줄과 동일한 컨텍스트에서 실행하십시오.

편집 : 애플 버그살펴보면 실제 결과가 매우 심각한이 정확한 문제의 완벽한 예를 볼 수 있습니다.goto fail

if( true )
    doSomething();

된다 ...

if( true )
    doSomething();
    doSomethingElse();

이 경우 doSomethingElse()테스트 결과에 관계없이 매번 실행되지만 doSomething()명령문 과 같은 수준으로 들여 쓰기 때문에 놓치기 쉽습니다. 이것은 실제로 논쟁의 여지가 없습니다. 이것을 다시 연구하십시오. 이것은 유지 관리 중에 소스 코드에 도입 된 큰 버그 소스입니다.

그래도 JavaScript 클로저 구문은 자신의 줄에 중괄호가있는 약간 어리석은 것처럼 보입니다 ... 미학적으로. :-)


13
조건부에서 블록에 대한 부분은 약간 오도됩니다. C에서 조건부에는 항상 단일 명령문이 있지만 블록 (일명 복합 명령문) 은 일종의 명령문 입니다. C #은이 선례를 따릅니다. 어쨌든 조건부 평가 는 모든 공통 명령어 세트의 선형 특성으로 인해 항상 일종의 조건부 이동 또는 분기 명령어를 의미합니다. 블록이없는 조건은 블록이있는 조건과 질적으로 다르지 않습니다 (범위 지정 제외).
amon

3
@Craig, 이것은 Bell Labs에 있었으며 Bell Labs가 "흥미로운 일을"해야한다는 사실을 기억하십시오. 똑똑한 사람들을 건물에 넣고, 흥미로운 연구를하고, 그들이 "흥미롭지 않은"것에서 벗어나게하고, 재미있는 것은 흥미로운 것들 (트랜지스터 나 유닉스와 같은)이 튀어 나오는 경향이 있다는 것입니다. DARPA는 처음에 같은 초점을 맞추었고 기본 연구라는 이름으로 많은 훌륭한 연구에 자금을 지원했습니다.
John R. Strohm

3
@Craig : Pascal / Delphi 시절에는 Pascal이 사용 begin하고 end중괄호 대신 단일 행 블록에 대해 일반적으로 피했습니다. 작년 4 일 임베디드 C에서 문제를 디버깅하는 중괄호 배치 부족으로 인해 결국 ..... 제어문에 중괄호를 필수로 만드는 컴파일러 옵션이 있어야한다고 생각합니다!
Mark K Cowan

12
"... 자신의 줄에 중괄호가 있음을 보여주는 과학적 연구에 대한 참조를 제공하십시오 ...". 적어도 두 개의 참조가 없으면 (그렇지 않으면 연구 가 아닌 연구 가 될 것입니다 ), 무작위로 공중으로 쏘고 있습니다.
ErikE

2
@Craig, 언급 한 연구 연구를 찾는 방법에 대한 단서를 제공해 줄 수 있습니까?
Grzegorz Adam Kowalski

30

C # 개발자가하는 이유는 Visual Studio 자동 포맷터의 기본 설정이기 때문입니다. 이 설정은 변경할 수 있지만 대부분의 사람들은 변경하지 않으므로 팀의 모든 개발자가 대다수와 함께 가야합니다.

왜 이것이 Visual Studio에서 기본값인지는 모르겠습니다.


15
Visual Studio의 기본 스타일은 Microsoft에서 일반적으로 받아 들여지는 코딩 스타일이기 때문에 실제로는 Microsoft의 일부 팀에서는 스타일이 자체 줄에 중괄호 일뿐 만 아니라 자체 줄에 중괄호였습니다 들여 쓰기. 따라서 Visual Studio의 옵션이기도합니다 (개인적으로 선호합니다).
Craig

20
@Craig : Ewwwwwwwww
Monica와의 가벼움 경주

5
@PreferenceBean 흠. 개인적으로 나는 K & R 스타일을 좋아하지 않습니다. 왜냐하면 괄호가 줄 끝에서 소음이 없어지고 텍스트가 나에게 딱딱하게 보이기 때문입니다. 이는 미적 선호가 아니라 가독성 / 독해에 실제로 영향을 미칩니다. 나는 수직 공백을 좋아한다. 예전에는 수직 공간이 소중했던 24 줄의 텍스트가있는 12 인치 모니터에서는 약간 달랐습니다.
Craig

10
@Craig : 괄호를 들여 쓰는 데 대한 변명의 여지가 없습니다 : P
Monica와의 가벼운 경주

2
@Craig Microsoft 직원을 비참하게 만들려면?
Mateen Ulhaq

18

https://softwareengineering.stackexchange.com/a/159081/29029- 이 답변에서 가설을 세웠 듯이 Hejlsberg가 C #을 디자인하기 전에 Delphi를 만들었을 때 Allman의 브레이싱과 함께하기로 결정한 것은 파스칼 유산의 징후 일 수 있다고 생각합니다 . 메소드 이름에 대한 파스칼 케이스와 동일합니다.

개인적으로 나는 "로마에서 로마인들이하는 것처럼"이라는 속담을 따르는 것을 믿는다. C #에서는 Allman을 사용하고 Java에서는 K & R을 사용합니다. 컨벤션을 바꾸는 것이 저에게있어 굉장히 익숙합니다.

나는 어떤 컨벤션 다양성이 실제로 "다국어"개발자에게 도움이된다고 생각합니다. 현재 어떤 언어를 코딩하고 있는지 기억하고 다양한 습관을 쉽게 구분할 수 있기 때문입니다. 말하자면 근육 기억과 정신적으로 같습니다.


7
실제로 "다국어 개발자"라인의 경우 +1입니다. 나는 진지하게 중괄호를 선호하고 들여 쓰기를 선호합니다. 그러나 ASP.NET (MVC) 프로젝트와 같은 작업에서 필자는 "올바른"스타일의 C #과 "자바 스크립트"스타일의 JavaScript를 좋아합니다. 그것은 뺨에 약간의 혀이지만 솔직히 그중 일부는 JavaScript의 종료 구문이 줄 끝에 괄호로 더 매력적이라는 것입니다. 그래서 나는 다른 사람만큼 미학의 노예입니다 ...
Craig

메소드 이름에 대한 PascalCase는 Anders Hejlsberg가 Microsoft에서 뛰어난 소프트웨어 엔지니어로 Borland를 떠나기 오래 전에 Microsoft의 표준이었습니다 .
Craig

2
흥미롭게도 저는 모든 중괄호 언어에 Allman을 사용합니다. 그러나 들여 쓰기를 들여 쓰기를 중괄호 블록으로 변환하는 것이 Java에서 어떻게 보이는지에 대한 관심이 높아지고 있습니다. "자바"코드는 패턴 인식을 감싸면 깔끔하게 보일 수 있습니다. 파이썬은 실제로 바로이있을 수 있습니다 생각 : 정말 아무있다 훌륭한 언어에 중괄호에 대한 이유는.
tgm1024

공백을 사용하여 프로그램 흐름을 제어하는 ​​것은 광기입니다. 파이썬은 요즘 인기가 있지만, 파이썬의 이런 측면은 처음 등장한 이후 약간 미쳤다.
Craig

@Craig Python 팬이 여기에 자바 스크립트로 무언가를 얻으려고합니다. goto fail들여 쓰기를 사용하여 프로그램 흐름을 제어하는 다른 답변과에 대한 편집 내용을 살펴보면 인간이 자연스럽게하고 싶은 일이 무엇인지 알 수 있습니다. 들여 쓰기가 잘못되면 평범하지 않습니다. 실제로 들여 쓰기를 반영하는지 여부에 따라 중괄호의 의미를 해독해야하는 것은 프로그램을 이해하는 것 이상의 추가 작업입니다. 들여 쓰기는 중괄호에 중복되므로 중괄호가 유용한 경우 프로그래머가이를 사용하는 이유는 무엇입니까? 딥 네 스팅은 모든 언어에서 이해할 수 없습니다. Jus 'sayin'.
Neil_UK

14

Java와 연관되는 규칙은 K & R 스타일 또는 "하나의 괄호 스타일"이며 원래는 C에서 온 것입니다.이 전문적인 전문 용어 파일의 들여 쓰기 스타일 은 구별이 얼마나 오래된지를 보여줍니다.

나는 Allman 스타일과 그 변형이 저자가 코드에 대해 어떻게 생각 하는지를 반영하여 블록 구분 기호를 일부 언어에서 코드 블록 주위에서 "시작"및 "종료"를 사용하는 것과 유사한 키워드 수준으로 높이는 것이라고 생각했습니다.


요즘 OTBS (하나의 중괄호 스타일)는 단 한 줄의 코드조차도 제어 문 뒤에 중괄호를 절대로 남기지 않는다는 인상을 받고 있습니다. Apple goto fail 버그를 참조하십시오.
크레이그
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.