블록-중괄호 아니면 아니오? [닫은]

어느 것이 더 낫고 더 일반적으로 받아 들여 집니까?

이:

if(condition)
{
  statement;
}

또는:

if(condition)
  statement;

나는 첫 번째 것을 선호하는 경향이 있습니다. 왜냐하면 실제로 if 블록에 속하는 것을 쉽게 알 수있게하고 나중에 다른 괄호를 추가하지 못하게하거나 잊어 버림으로써 버그를 만드는 것을 방지하고 모든 if 문을 만듭니다. 중괄호와 일부가없는 일부 대신 유니폼. 그러나 두 번째 것은 여전히 ​​문법적으로 정확하고 확실히 더 컴팩트합니다. 그래도 다른 사람들이 더 일반적으로 선호하는 것을 알고 싶습니다.

첫 번째는 오류가 발생하기 쉽기 때문에 더 좋습니다. 예를 들어, 코드를 일시적으로 주석 처리하여 무언가를 디버깅한다고 가정 해 봅시다.

if(condition) 
//      statement;
otherStatement;

또는 서둘러 코드를 추가하십시오.

if(condition) 
    statement;
    otherStatement;

이것은 분명히 나쁘다. 반면에, 첫 번째 것은 때때로 너무 장황하게 느껴집니다. 따라서 충분히 짧고 간단하다면 모든 것을 한 줄에 넣는 것을 선호합니다.

if(condition) statement;

이것은 구문 노이즈를 줄이면서 구문이 실제로하는 것처럼 보이게하여 오류가 덜 발생하게합니다. 이 구문은 매우 간단하고 짧은 조건과 문장에만 사용된다는 점에서 완벽하게 읽을 수 있습니다.

나는 항상 안전을 위해 대괄호를 사용합니다.

글을 쓰면 괜찮지 만 앞으로 누군가가 와서 대괄호를 넣지 않고 다른 진술을 삽입 할 것입니다.

가능한 경우 중괄호 가 없는 버전을 선호 합니다.

다음 설명은 길다. 저를 참아주세요. 나는이 스타일을 선호하는 강력한 이유를 제시 할 것이다. 또한 왜 일반적인 반론이지지되지 않는다고 생각하는지 설명 할 것입니다.

(근처) 빈 줄은 낭비입니다

그 이유는 닫는 중괄호에 추가 코드 줄이 필요하고 스타일에 따라 여는 중괄호도 필요하기 때문입니다. ¹

이것이 큰 문제입니까? 피상적으로 결국 대부분의 사람들은 코드에 빈 줄을 넣어 논리적으로 약간 독립적 인 블록을 분리하여 가독성을 크게 향상시킵니다.

그러나 수직 공간 낭비를 싫어했습니다. 현대 모니터에는 실제로 수평 공간이 충분합니다. 그러나 수직 공간은 여전히 ​​매우 제한적입니다 (모니터를 똑바로 사용하지 않는 한 드문 일이 아닙니다). 이 제한된 수직 공간 은 문제입니다. 개별 방법은 가능한 한 짧아야하고 해당 버팀대 (또는 다른 블록 구분 기호)는 화면 높이 차이가 아니어야 전체 블록을 볼 수 있습니다. 스크롤.

이것은 근본적인 문제입니다. 일단 화면에서 전체 블록을 더 이상 볼 수 없으면 파악하기가 복잡해집니다.

결과적으로 중복 된 빈 줄이 표시됩니다. 하나의 빈 줄이 독립 블록을 구분하는 데 중요한 경우 (이 텍스트의 시각적 모양을 보아라) 연속적인 빈 줄은 내 책에서 매우 나쁜 스타일이며 내 경험상 일반적으로 초보자 프로그래머의 표시입니다.

마찬가지로, 단순히 버팀대를 고정하고 절약 할 수있는 라인이 있어야합니다. 중괄호로 구분 된 단일 문 블록은 1 ~ 2 줄을 낭비합니다. 화면 높이 당 50 줄만 있으면 눈에.니다.

중괄호를 생략하면 해를 끼치 지 않을 수 있습니다.

중괄호 생략에 대한 단 하나의 주장 이 있습니다 . 누군가 나중에 문제의 블록에 다른 명령문을 추가하고 중괄호를 추가하는 것을 잊어 버려 코드의 의미를 실수로 변경한다는 점입니다.

이것은 실제로 큰 일이 될 것입니다.

그러나 내 경험으로는 그렇지 않습니다. 나는 조잡한 프로그래머입니다. 그러나 수십 년의 프로그래밍 경험에서 솔직히 말하면 싱글 톤 블록에 추가 명령문을 추가 할 때 중괄호를 추가하는 것을 잊어 버리지 않았다고 말할 수 있습니다 .

나는 이것이 일반적인 실수 여야한다는 것을 믿기 어려워합니다. 블록은 프로그래밍의 기본 부분입니다. 블록 레벨 분석 및 범위 지정은 프로그래머에게 자동으로 심화 된 프로세스입니다. 뇌는 단지 그렇게한다 (그렇지 않으면 프로그래밍에 대한 추론은 훨씬 더 어려울 것이다). 중괄호를 기억하는 데 추가로 정신적 인 노력이 필요하지 않습니다. 프로그래머는 또한 새로 추가 된 명령문을 올바르게 들여 쓰는 것을 기억 합니다. 프로그래머는 이미 블록이 포함되도록 정신적으로 처리했습니다.

이제, 나는 하지 중괄호를 생략하는 실수를 유발하지 않는 말. 내가 말하는 것은 우리에게 어떤 식 으로든 다른 증거가 없다는 것입니다. 우리는 단순히 그것이 해를 끼치는 지 모릅니다 .

따라서 누군가가 과학 실험에서 수집 한 하드 데이터를 보여줄 때까지 이것이 실제로 실제로 문제가된다는 것을 보여줄 때까지,이 이론은“ 정확한 이야기 ”로 남아 있습니다. 인수로 사용 해서는 안됩니다 .

¹ 이 문제는 중괄호를 포함하여 모든 것을 같은 줄에 놓아서 때때로 해결됩니다.

if (condition)
{ do_something(); }

그러나 나는 대부분의 사람들이 이것을 멸시한다고 말하는 것이 안전하다고 생각합니다. 또한 중괄호가없는 변형과 동일한 문제가 있으므로 두 세계에서 최악입니다.

나는 두 번째로 간다. 더 간결하고 덜 장황합니다.

최저 공통 분모에 쓰지 않으려 고 노력하므로 다른 개발자가 오늘날 프로그래밍에서 가장 일반적인 단일 제어 흐름 구조 중 하나를 작성하는 방법을 알고있을 것으로 기대합니다.

나는 다음을 사용한다 (여기의 합의) :

if (condition) {
    any_number_of_statements;
}

또한 가능합니다 :

if(condition) single_compact_statement;

특히 C / C ++와 같은 언어에서는 좋지 않습니다.

if(condition) 
    single_compact_statement;

( 파이썬 에서는 선택의 여지가 없습니다 ;-)

에서 펄 , 당신은 사용하십시오 :

$C = $A**3 if $A != $B;

또는

$C = $A**3 unless $A == $B;

(이것은 의사 코드 가 아닙니다 ;-)

위의 모든 이유로 더하여 중괄호 방법을 사용합니다.

코드 병합 자동 병합으로 인해 해당 단일 문에서 작업 한 프로젝트에서 발생하는 것으로 알려져 있습니다. 무서운 것은 코드가 잘못되어도 들여 쓰기 가 올바르게 보이 므로이 유형의 버그를 찾기가 어렵습니다.

그래서 나는 중괄호로 간다-그들 자신의 선에. 그런 식으로 레벨을 발견하는 것이 더 쉽습니다. 그렇습니다. 수직 화면 공간을 낭비하고 진정한 단점입니다. 균형을 잡으면 그만한 가치가 있다고 생각합니다.

중괄호가 없습니다. 다른 프로그래머가 내 코드에 두 번째 문장을 추가하면 누군가 내 차를 운전하게하고 절벽을 넘어가는 것보다 내 잘못이 아닙니다.

우리는 여기서이 주장을 두 번 이상했습니다. 그리고 전반적인 합의는 항상 중괄호를 사용하는 것입니다. 주요 이유는 가독성 / 유지 보수성에 관한 것입니다.

if블록 에 코드를 추가해야하는 경우 중괄호를 기억 / 검색 할 필요가 없습니다. 미래의 프로그래머가 코드를 읽을 때 중괄호는 항상 분명합니다.

플러스 측면에서 ReSharper 는 Visual Studio에서 게으른 프로그래머를위한 중괄호를 자동으로 추가하며 다른 IDE 에도 애드온이 있다고 가정 합니다.

나는 거의 예외없이 첫 번째 구문을 사용합니다. 잘못 해석 될 수 없기 때문 입니다.

"나를 생각하지 마라"는 단지 사용자 인터페이스에만 적용되는 것이 아니다.

나는 개인적으로 두 번째를 선호합니다. 첫 번째는 추악하고 어색하며 가로 공간을 낭비합니다. 두 번째 문제의 주요 문제점은 매크로와 나중에 코드를 잘못 수정하는 사람들입니다.

이를 위해 "매크로를 사용하지 마십시오"라고 말합니다. 또한 "담당자 코드를 올바르게 들여 쓰기"라고 말합니다. 프로그래밍에 사용되는 모든 텍스트 편집기 / IDE가 자동으로 들여 쓰기를 수행하는 방식을 고려할 때 그렇게 어렵지 않아야합니다. Emacs에서 코드를 작성할 때, 자동 들여 쓰기를 사용하여 이전 행에 잘못된 내용을 작성했는지 식별합니다. 이맥스가 들여 쓰기를 망칠 때마다 나는 보통 내가 잘못한 것을 알고있다.

실제로, 나는 나 앞에서 설정된 코딩 규칙을 따르게됩니다. 그러나 이것들은 저를 성가 시게합니다 (그리고 파이썬으로 코딩 할 때이 전체 브래킷 재앙이 사라지면 훨씬 행복 해집니다)

if (condition) {
    statement;
} // stupid extra brace looks ugly

그때

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

솔직히 if 문의 두 문장은 단일 문장보다 훨씬 더 귀찮습니다. 대부분의 경우 대괄호가 필요하고 if 문에 두 개의 문만 있으면 여전히 재미있게 보입니다.

중괄호없이 두 줄 버전을 사용하지만 (두 번째 형식) 공간을 절약하기 위해 사용하지 않습니다.

더 읽기 쉽고 시각적으로 매력적이며 입력하기가 쉬우므로이 양식을 사용합니다. 해당 조건이 충족되는 경우에만 해당 양식을 사용합니다. 즉, if조건은 한 줄에 잘 맞아야하고 해당 명령문은 다음 줄에 잘 맞아야합니다. 그렇지 않은 경우 가독성을 높이기 위해 중괄호를 사용합니다.

이 양식을 사용하는 경우 if명세서 전후 (또는 주석이있는 경우) 위에 빈 줄 (또는 중괄호 만 포함 된 줄)이 있는지 확인합니다 . 이것은 내가 의식적으로 따르는 규칙은 아니지만,이 질문을 읽은 후에는 지금 그것을 알아 차립니다.

화면 공간을 절약하는 것이 우선 순위가 아닙니다. 더 많은 공간이 필요하면 더 큰 모니터를 사용합니다. 내 화면은 이미주의를 기울여야 할 내용을 읽을 수있을만큼 충분히 큽니다. 한 번에 너무 많은 코드 줄에 집중하여 전체 화면을 차지할 가능성은 거의 없습니다. 한 번에 더 많은 코드를 보지 않고는 이해할 수없는 코드 덩어리로 중첩이 너무 많으면 리팩토링으로 논리를 더 잘 나타낼 수 있는지 고려해야합니다.

다음은이 양식의 if진술을 어떻게 사용하는지 보여주는 몇 가지 예입니다 .

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

바지 멜빵. 항상. 코드에 일관성을 부여하기 때문에 나는 그 팬들입니다. 또한 @dsimcha가 작성한 것처럼 코드 줄을 추가 할 때 오류가 발생할 가능성이 적습니다.

한 줄의 코드 주위에 중괄호의 "Ugliness"는 디버깅 및 / 또는 코드 추가의 경우에 발생할 수있는 추가 작업보다 덜 해 롭습니다.

개인적으로 나는 대괄호로 간다.

왜?

누군가가 와서 if 문에 코드를 추가 해야하는 경우 범위가 어디에 있는지 100 % 명확합니다.

if블록에 몇 개의 명령문이 있는지에 관계없이 명령문 형식을 일관되게 유지합니다 .

그러나 프로젝트 스타일이 없어지면 그 스타일을 고수하십시오.

나는 항상 항상 안전을 위해 괄호를 사용합니다. 그러나 때로는 블록의 내용이 실제로 짧은 경우에는 그대로두고 하나의 라이너로 만듭니다.

if (x==5) Console.WriteLine("It's a five!");

일관성을 위해 중괄호를 선호하지만 너무 많은 공백을 낭비하지 않습니다 (더 읽기 쉬운 형식의 코드는 제한된 시야에 있습니다). 그래서 나는 이것을 짧은 줄로 작성합니다.

If (cond) { statement; }

나는 보통 중괄호를 사용하지만, 그렇지 않은 경우가 있습니다.

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

나에게 그것들을 추가하는 것은 어리석은 일입니다. 누군가 다음에 문을 추가하면 return범위 지정 문제보다 더 큰 문제가 있습니다.

IDE에 코드 형식이 있으면 중괄호를 사용하지 않습니다.

반면에 자동 서식을 지원하지 않는 다른 편집기에서 코드를 편집 할 수있는 경우 다른 게시물에 언급 된대로 중괄호를 사용하지 않는 것이 위험합니다. 그러나 그럼에도 불구하고 중괄호를 사용하지 않는 것이 좋으며 문제가되지 않았습니다.