단일 행 if 또는 루프에 중괄호 (예 : {})를 사용하는 목적은 무엇입니까?

C ++ 강사의 강의 노트를 읽고 다음과 같이 썼습니다.

1. 들여 쓰기 사용 // 확인
2. 연산자 우선 순위에 의존하지 않음-항상 괄호 사용 // 확인
3. 항상 {} 블록을 사용 - 심지어 한 줄 //을 위해 하지 OK , 왜 ???
4. 비교의 왼쪽에있는 Const 객체 // 확인
5. > = 0 // 멋진 트릭 인 변수에는 부호없는 것을 사용하십시오.
6. 삭제 후 포인터를 NULL로 설정-이중 삭제 보호 // 나쁘지 않음

세 번째 기술은 나에게 분명하지 않습니다. 한 줄을 { ... }?

예를 들어,이 이상한 코드를 보자 :

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

그것을 다음으로 대체하십시오 :

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;

첫 번째 버전을 사용하면 어떤 이점이 있습니까?

i증분 할 때도 수정 해 봅시다 j:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
        i++;

아뇨! 파이썬에서 나오면 괜찮아 보이지만 실제로는 다음과 같습니다.

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

물론 이것은 어리석은 실수이지만 숙련 된 프로그래머조차도 할 수있는 실수입니다.

또 다른 좋은 이유 는 ta.speot.is 's answer 에서 지적합니다 .

내가 생각할 수 있는 세 번째 는 nested입니다 if.

if (cond1)
   if (cond2) 
      doSomething();

이제, 당신이 지금 원하는 가정 doSomethingElse()할 때 cond1(새로운 기능)이 충족되지 않습니다. 그래서:

if (cond1)
   if (cond2) 
      doSomething();
else
   doSomethingElse();

이는 elseinner와 연관 되기 때문에 분명히 잘못되었습니다 if.

편집 : 이것은 약간의 관심을 받고 있기 때문에 내 견해를 분명히 할 것입니다. 내가 대답 한 질문은 다음과 같습니다.

첫 번째 버전을 사용하면 어떤 이점이 있습니까?

내가 설명 한 것. 몇 가지 이점이 있습니다. 그러나 "항상"규칙이 항상 적용되는 것은 아닙니다. 전 전적으로지지하지 않습니다

항상 {} 블록을 사용하십시오-한 줄이라도 // 안 좋아, 왜 ???

나는 항상{} 블록을 사용 한다고 말하는 것이 아닙니다 . 충분히 간단한 상태와 행동이라면하지 마십시오. 누군가 나중에 와서 코드를 변경하여 기능을 추가 할 수 있다고 생각되면 그렇게하십시오.

이 코멘트를 사용하지 않는 경우와 실수로 변경 제어 흐름에 매우 쉽게 {하고 }. 예를 들면 다음과 같습니다.

if (condition)
  do_something();
else
  do_something_else();

must_always_do_this();

당신이 주석 경우 do_something_else()한 줄의 코멘트와 함께, 당신은이 될 겁니다 :

if (condition)
  do_something();
else
  //do_something_else();

must_always_do_this();

컴파일되지만 must_always_do_this()항상 호출되는 것은 아닙니다.

우리는 코드베이스에이 문제가 있었는데, 누군가 릴리스 전에 일부 기능을 매우 빠르게 비활성화하기 시작했습니다. 다행히도 우리는 코드 검토에서 그것을 잡았습니다.

강사의 역량에 대해서는 의문의 여지가 있습니다. 그의 요점을 고려하면 :

1. 확인
2. 누구든지 정말로 쓰거나 읽을 (b*b) - ((4*a)*c)래요? 일부 우선 순위는 분명하고 (또는 있어야 함) 여분의 괄호는 혼란에 추가됩니다. (반면, 필요하지 않다는 것을 알더라도 덜 명확한 경우에 괄호를 사용해야합니다.)
3. 일종의. 조건부 및 루프의 형식을 지정하는 데 널리 사용되는 두 가지 규칙이 있습니다.

   if (cond) {
       암호;
   }
   

   과:

   if (cond)
   {
       암호;
   }
   

   첫 번째로 나는 그에게 동의 할 것이다. 개구부 {는 그렇게 보이지 않으므로 항상 존재한다고 가정하는 것이 가장 좋습니다. 그러나 두 번째로, 나는 (그리고 내가 함께 일한 대부분의 사람들은) 단일 진술에 중괄호를 생략하는 데 아무런 문제가 없습니다. (물론 들여 쓰기는 체계적이며이 스타일을 일관되게 사용하도록 제공했습니다. (그리고 매우 좋은 프로그래머는 읽기 쉬운 코드를 작성하여 첫 번째 형식을 지정할 때에도 중괄호를 생략했습니다.)
4. 아니요 . if ( NULL == ptr )가독성을 방해하기에는 못생긴 것들이 있습니다. 비교를 직관적으로 작성하십시오. (많은 경우 오른쪽에 일정한 결과가 나타납니다.) 그의 4 가지는 나쁜 조언입니다. 코드를 부 자연스럽게 만드는 것은 코드를 읽기 어렵게 만듭니다.
5. 아니요 . int특별한 경우를 제외하고 는 아무것도 없습니다 . 숙련 된 C 및 C ++ 프로그래머에게는 unsigned신호 비트 연산자를 사용합니다. C ++에는 실제 기본 유형 (또는 다른 효과적인 하위 범위 유형)이 없습니다. unsigned승격 규칙으로 인해 숫자 값에는 작동하지 않습니다. 일련 번호와 같이 산술 연산이 의미가없는 숫자 값은 아마도 일 수 있습니다 unsigned. 그러나 잘못된 메시지를 보내기 때문에 반대 의견을 제시합니다. 비트 연산도 의미가 없습니다. 기본 규칙은 정수 유형이 int_unless_이고 다른 유형을 사용해야 하는 중요한 이유가 있다는 것입니다.
6. 아니요 . 이를 체계적으로 수행하는 것은 오해의 소지가 있으며 실제로 어떤 것도 보호하지 못합니다. 엄격한 OO 코드에서, delete this;(당신은 설정할 수 없습니다 종종 가장 흔한 경우가 this로 NULL), 그렇지 않으면, 대부분은 delete나중에 어쨌든 포인터를 액세스 할 수 있도록 소멸자에 있습니다. 그리고 그것을 설정하면 NULL다른 포인터가 떠 다니는 것에 대해 아무것도하지 않습니다. 체계적으로 포인터를 설정하면 NULL잘못된 보안 감각이 생겨 실제로 아무것도 사지 않습니다.

일반적인 참조에서 코드를 확인하십시오. Stroustrup은 예를 들어 첫 번째 규칙을 제외한 모든 규칙을 위반합니다.

다른 강사를 찾으십시오. 실제로 자신이 말하는 것을 아는 사람.

다른 모든 답변은 강사의 규칙 3을 방어합니다.

내가 당신에게 동의한다고 말합시다. 규칙은 중복 적이고 나는 조언하지 않을 것입니다. 항상 중괄호를 추가하면 이론적으로 오류를 방지 하는 것이 사실입니다 . 다른 한편으로, 나는 실제 생활 에서이 문제를 겪어 본 적이 없습니다 . 다른 답변이 암시하는 것과는 달리, 일단 필요한 경우 중괄호를 추가하는 것을 잊지 않았습니다. 적절한 들여 쓰기를 사용하는 경우, 하나 이상의 명령문이 들여 쓰기되면 중괄호를 추가해야한다는 것이 즉시 명백해집니다.

“Component 10”의 답변은 실제로 이것이 실제로 오류를 일으킬 수있는 유일하게 가능한 사례를 강조합니다. 그러나 정규 표현식을 통해 코드를 교체하면 항상 막대한주의가 필요합니다.

이제 메달의 다른 쪽을 살펴 보자. 항상 중괄호를 사용 하는 것이 불리한가? 다른 대답은 단순히이 점을 무시합니다. 그러나이 있다 단점 : 그것은 수직 화면 공간을 많이 차지, 그리고 당신이 필요 이상으로 스크롤해야 할 의미하기 때문에이 차례로 코드를 읽을 수 있습니다.

처음에 많은 가드 절이있는 함수를 고려하십시오 (예, 다음은 나쁜 C ++ 코드이지만 다른 언어에서는 매우 일반적인 상황입니다).

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
    {
        throw null_ptr_error("a");
    }
    if (b == nullptr)
    {
        throw null_ptr_error("b");
    }
    if (a == b)
    {
        throw logic_error("Cannot do method on identical objects");
    }
    if (not a->precondition_met())
    {
        throw logic_error("Precondition for a not met");
    }

    a->do_something_with(b);
}

이것은 끔찍한 코드이며 다음이 훨씬 더 읽기 쉽다고 강력하게 주장합니다.

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
        throw null_ptr_error("a");
    if (b == nullptr)
        throw null_ptr_error("b");
    if (a == b)
        throw logic_error("Cannot do method on identical objects");
    if (not a->precondition_met())
        throw logic_error("Precondition for a not met");

    a->do_something_with(b);
}

마찬가지로 짧은 중첩 루프는 중괄호를 생략하면 이점이 있습니다.

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
        for (auto j = 0; j < a.h(); ++j)
            c(i, j) = a(i, j) + b(i, j);

    return c;
}

다음과 비교하십시오 :

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
    {
        for (auto j = 0; j < a.h(); ++j)
        {
            c(i, j) = a(i, j) + b(i, j);
        }
    }

    return c;
}

첫 번째 코드는 간결합니다. 두 번째 코드는 부풀어 오른다.

그리고 예, 이것은 이전 줄에 오프닝 버팀대를 놓음으로써 어느 정도 완화 될 수 있습니다 . 하지만 그 것이다 아직 어떤 중괄호가없는 코드보다 덜 읽을 수.

한마디로 : 화면 공간을 차지하는 불필요한 코드를 작성하지 마십시오.

내가 작업중 인 코드베이스는 중괄호로 병적 혐오감을 가진 사람들에 의해 코드로 흩어져 있으며, 나중에 오는 사람들에게는 실제로 유지 보수성과 차이를 만들 수 있습니다.

가장 자주 문제가되는 예는 다음과 같습니다.

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
    this_looks_like_a_then-statement_but_isn't;

그래서 내가 와서 then-statement를 추가하고 싶을 때, 조심하지 않으면 쉽게 끝낼 수 있습니다.

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
    this_looks_like_a_then-statement_but_isn't;
    i_want_this_to_be_a_then-statement_but_it's_not;
}

그것이 왜 당신은 이제까지 것, 디버깅 몇 혼란 분 ~ 소요 일초 괄호를 추가하고 최소한 당신을 저장할 수있는 점을 감안 하지 감소 - 모호한 옵션으로 이동? 나에게 거짓 경제처럼 보인다.

내 2c :

들여 쓰기 사용

명백하게

연산자 우선 순위에 의존하지 마십시오-항상 괄호를 사용하십시오

"항상" "항상"이라는 단어는 사용하지 않지만 일반적으로이 규칙이 유용하다는 것을 알 수 있습니다. 일부 언어 (Lisp, Smalltalk)에서는 문제가되지 않습니다.

한 줄이라도 항상 {} 블록을 사용하십시오

나는 그런 일을 한 번도하지 않고 한 가지 문제도 겪지 않았지만 그것이 어떻게 학생들에게 좋은지 알 수 있습니다. 그들이 전에 파이썬을 공부했다면.

비교의 왼쪽에있는 Const 객체

요다 조건? 아니요 괜찮아요. 가독성이 떨어집니다. 코드를 컴파일 할 때 최대 경고 수준을 사용하십시오.

> = 0 인 변수에는 부호없는 것을 사용하십시오.

확인. 재미 있지만 Stroustrup이 동의하지 않는다고 들었습니다.

삭제 후 포인터를 NULL로 설정-이중 삭제 방지

나쁜 충고! 삭제되었거나 존재하지 않는 객체를 가리키는 포인터가 없습니다.

보다 직관적이고 쉽게 이해할 수 있습니다. 의도를 명확하게합니다.

그리고 그것은 새로운 사용자가 모르는 사이를 놓칠 수있는 경우 코드가 침입하지 않도록합니다 {, }새로운 코드 문을 추가하는 동안.

위의 매우 현명한 제안에 추가하기 위해 이것이 중요하게되는 일부 코드를 리팩토링하는 동안 발생한 한 가지 예는 다음과 같습니다. 한 API에서 다른 API로 전환하도록 매우 큰 코드베이스를 변경하고있었습니다. 첫 번째 API에는 다음과 같이 회사 ID를 설정하라는 호출이있었습니다.

setCompIds( const std::string& compId, const std::string& compSubId );

반면 교체품에는 두 가지 전화가 필요했습니다.

setCompId( const std::string& compId );
setCompSubId( const std::string& compSubId );

나는 매우 성공적인 정규 표현식을 사용하여 이것을 변경하는 것에 대해 설정했습니다. 또한 astyle을 통해 코드를 전달하여 실제로 훨씬 더 읽기 쉽게 만들었습니다. 그런 다음 검토 프로세스를 진행하는 동안 조건부 상황에서 다음과 같이 바뀌고 있음을 발견했습니다.

if ( condition )
   setCompIds( compId, compSubId );

이에:

if ( condition )
   setCompId( compId );
setCompSubId( compSubId );

그것은 분명히 무엇이 필요한 것이 아닙니다. 나는 블록으로 교체를 완전히 처리 한 다음 구피로 보이는 것을 수동으로 변경하여 처음부터 다시해야했습니다 (적어도 틀리지 않습니다).

나는 astyle 에 옵션 --add-brackets이 없어서 대괄호를 추가 할 수 있는 옵션 이 없다는 것을 알았습니다.

나는 {}명백한 몇 가지 경우를 제외하고 어디에서나 사용 하고 있습니다. 한 줄은 다음 중 하나의 경우입니다.

if(condition) return; // OK

if(condition) // 
   return;    // and this is not a one-liner 

반환하기 전에 몇 가지 방법을 추가하면 손상 될 수 있습니다. 들여 쓰기는 조건이 충족 될 때 리턴이 실행 중임을 나타내지 만 항상 리턴합니다.

statment를 사용하는 C #의 다른 예

using (D d = new D())  // OK
using (C c = new C(d))
{
    c.UseLimitedResource();
}

어느 것이

using (D d = new D())
{
    using (C c = new C(d))
    {
        c.UseLimitedResource();
    }
}

내가 생각할 수있는 가장 적절한 예는 다음과 같습니다.

if(someCondition)
   if(someOtherCondition)
      DoSomething();
else
   DoSomethingElse();

어떤 if는 것 else과 쌍? 들여 쓰기는 바깥 쪽이을 if얻는다는 것을 의미 else하지만 실제로 컴파일러가 그것을 보는 방법은 아닙니다. 내부 if 을 얻을 것이다 else, 및 외부if 하지 않습니다. 이 코드가 왜 기대에 미치지 못하는지 검사하여 파악하려면이를 알아야합니다 (또는 디버깅 모드에서 이와 같은 방식으로 작동하는 것을보십시오). 파이썬을 안다면 더 혼란스러워집니다. 이 경우 들여 쓰기가 코드 블록을 정의한다는 것을 알고 있으므로 들여 쓰기에 따라 평가 될 것으로 예상합니다. 그러나 C #은 공백에 대한 비행 플립을 제공하지 않습니다.

이제 저는이 "항상 대괄호 사용"규칙에 동의하지 않습니다. 코드를 매우 세로로 시끄럽게하여 빠르게 읽을 수있는 기능을 줄입니다. 진술이 다음과 같은 경우 :

if(someCondition)
   DoSomething();

... 이렇게 이렇게 작성해야합니다. "항상 대괄호 사용"이라는 문장은 "항상 괄호로 수학 연산을 둘러싸고 있습니다"와 같은 소리가납니다. 그것은 매우 간단한 진술을 a * b + c / d로 바꾸어 ((a * b) + (c / d))가까운 친척 (많은 코더의 골칫거리)을 놓칠 가능성을 소개하고 무엇을 위해? 작업 순서는 잘 알려져 있고 적용되므로 괄호는 중복됩니다. a * (b+c) / d예를 들어 일반적으로 적용되는 것과 다른 순서로 작업을 시행하기 위해 괄호 만 사용 합니다. 블록 버팀대는 비슷합니다. 기본값과 다르고 "명백하지 않은"(주관적이지만 일반적으로 꽤 상식적인) 경우에 수행하려는 작업을 정의하는 데 사용하십시오.

답을 살펴보면 아무도 습관을 들이지 않고 코드의 이야기를 들려주는 일종의 연습을 명시 적으로 언급하지 않았습니다.

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

된다 :

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0) j++;
}

퍼팅 j++온 같은 줄 다른 사람에게 신호를해야하는 경우로, "나는 오직 증가에이 블록을 원한다 j" . coursethis로, 여기에서 중단 점을 넣고 있기 때문에 라인은 가능한 한 단순한 같은 경우에만 가치가 요정이 언급 매우 유용 될 수 없습니다.

실제로 나는이 코드의 자바에서 '정렬'된 Twitter Storm API의 일부를 실행했습니다 . 이 슬라이드 쇼의 43 페이지 에서 실행 코드의 관련 스 니펫은 다음 과 같습니다 .

...
Integer Count = counts.get(word);
if (Count=null) count=0;
count++
...

for 루프 블록에는 두 가지가 있으므로 해당 코드를 인라인하지 않습니다. 즉 결코 :

int j = 0;
for (int i = 0 ; i < 100 ; ++i) if (i % 2 == 0) j++;

그것은 끔찍하며 그것이 의도 한대로 작동하는지조차 모릅니다. 하지 마십시오 . 새 줄과 중괄호는 쉼표 나 세미콜론이 산문에서하는 것과 같은 방식으로 분리되지만 관련된 코드 조각을 구별하는 데 도움이됩니다. 위의 블록은 몇 개의 절과 별도의 부분을 구별하기 위해 절대 멈추거나 멈추지 않는 다른 문장이있는 매우 긴 문장입니다.

실제로 다른 사람에게 전화를 걸려면 한 줄로만 작업해야하며 삼항 연산자 나 ?:양식을 사용하십시오.

for (int i = 0 ; i < 100 ; ++i) (i%2 ? 0 : >0) j++;

그러나 이것은 코드 골프에 영향을 미치고 있으며 좋은 습관은 아니라고 생각합니다 (j ++을 한쪽에 배치 해야하는지 여부는 명확 :하지 않습니다). NB 이전에 C ++에서 삼항 연산자를 실행하지 않았습니다.이 작동하는지 모르겠지만 존재합니다 .

한마디로 :

독자 (즉, 코드를 관리하는 사람)가 사용자의 스토리 (코드)를 어떻게 해석하는지 상상해보십시오. 가능한 한 명확하게하십시오. 초보자 코더 / 학생이 이것을 유지하고 있다는 것을 알고 있다면, {}가능한 한 많은 사람들 을 혼동하지 않도록하십시오.

이없는 문이 두 개 {}있으면 문제를 놓치기 쉽습니다. 코드가 다음과 같다고 가정 해 봅시다.

int error = 0;
enum hash_type hash = SHA256;
struct hash_value *hash_result = hash_allocate();

if ((err = prepare_hash(hash, &hash_result))) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &client_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &server_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &exchange_params)) != 0)
    goto fail;
    goto fail;
if ((err = hash_finish(hash)) != 0)
    goto fail;

error = do_important_stuff_with(hash);

fail:
hash_free(hash);
return error;

괜찮아 보인다. 특히 코드를 포함하는 함수가 더 큰 경우 문제가 발생하기 쉽습니다. 문제는 goto fail무조건 실행 된다는 것 입니다. 이것이 얼마나 실망 스러운지를 쉽게 상상할 수 있습니다 ( hash_update모든 것이 제대로 hash_update작동 한 후에 왜 마지막 이 실패 하는지 묻습니다 ).

그러나 이것이 내가 {}모든 곳 을 추가한다는 의미는 아닙니다 (내 의견으로 {}는 모든 곳을 보는 것이 성가시다). 문제가 발생할 수는 있지만 내 개인 코딩 스타일은 조건 {}이 동일한 행에 있지 않을 때 조건문을 금지하므로 내 프로젝트에는 결코 영향 을 미치지 않습니다. 다른 프로젝트에 기여할 때 프로젝트의 코드 스타일을 사용하십시오). 이것은 다음 코드를 잘 만듭니다.

if (something) goto fail;

그러나 다음은 아닙니다.

if (something)
    goto fail;

루프 및 조건부 블록의 범위를 명확하게 정의하여 코드를 더 읽기 쉽게 만듭니다. 또한 실수로 인한 실수를 방지합니다.

wrt 6 : 널 포인터를 삭제하면 아무런 문제가 없으므로 더 안전합니다. 따라서 실수로 해당 경로를 두 번 통과하면 메모리 손상으로 인해 여유 공간이 있거나 다른 것으로 할당 된 메모리가 해제되지 않습니다.

이는 수명이 매우 명확하지 않고 소멸 된 후 다시 생성되는 것으로 알려진 정적 파일 범위 객체 및 싱글 톤의 문제입니다.

대부분의 경우 auto_ptrs를 사용하여 필요를 피할 수 있습니다

나는 Luchian의 대답이 마음에 들었습니다. 사실 그가 옳은 것을 배웠기 때문에 한 줄 블록에도 항상 중괄호를 사용합니다. 그러나 귀하의 예와 같이 필터를 작성할 때 개인적으로 예외를 만듭니다. 이:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

나에게 어수선 해 보인다. 실제로 의도가 단일 조치 인 경우 for 루프와 if 문을 별도의 조치로 분리합니다 .2로 나눌 수있는 모든 정수를 세는 것이 더 표현적인 언어에서는 다음과 같이 작성할 수 있습니다.

j = [1..100].filter(_%2 == 0).Count

클로저가없는 언어에서는 필터를 단일 명령문으로 표현할 수 없지만 for 루프 다음에 if 문이 있어야합니다. 그러나 여전히 프로그래머가 생각하는 한 가지 조치이며 코드에 다음과 같이 반영되어야한다고 생각합니다.

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
  if (i % 2 == 0)
{
    j++;
}

위에서 설명한 오류를 방지하기위한 한 가지 옵션은 중괄호를 사용하지 않을 때 발생하는 작업을 인라인하는 것입니다. 코드를 수정하려고 할 때 오류를 눈치 채기가 훨씬 어렵습니다.

if (condition) doSomething();
else doSomethingElse();

if (condition) doSomething();
    doSomething2(); // Looks pretty obviously wrong
else // doSomethingElse(); also looks pretty obviously wrong

컴파일러라면 아무런 차이가 없습니다. 둘 다 동일합니다.

그러나 프로그래머에게는 첫 번째가 더 명확하고 읽기 쉽고 오류가 적습니다.

중괄호를 추가하는 또 다른 예입니다. 일단 버그를 찾고 있었고 그런 코드를 찾았습니다.

void SomeSimpleEventHandler()
{
    SomeStatementAtTheBeginningNumber1;
    if (conditionX) SomeRegularStatement;
    SomeStatementAtTheBeginningNumber2;
    SomeStatementAtTheBeginningNumber3;
    if (!SomeConditionIsMet()) return;
    OtherwiseSomeAdditionalStatement1;
    OtherwiseSomeAdditionalStatement2;
    OtherwiseSomeAdditionalStatement3;
}

메소드를 한 줄씩 읽으면 메소드에 true가 아닌 경우 리턴하는 조건이 있음을 알 수 있습니다. 그러나 실제로는 일부 조건에 따라 일부 변수를 설정하는 100 개의 다른 간단한 이벤트 핸들러처럼 보입니다. 그리고 언젠가 Fast Coder가 들어 와서 메소드 끝에 변수 설정 명령문을 추가합니다.

{
    ...
    OtherwiseSomeAdditionalStatement3;
    SetAnotherVariableUnconditionnaly;
}

결과적으로 SetAnotherVariableUnconditionnaly는 SomeConditionIsMet () 일 때 실행되지만 모든 행의 크기가 거의 비슷하고 반환 조건이 세로로 들여 쓰기되어 있어도 눈에 띄지 않습니다.

조건부 반환 형식이 다음과 같은 경우 :

if (!SomeConditionIsMet())
{
    return;
}

그것은 매우 눈에 띄고 빠른 코더는 한 눈에 찾을 것입니다.

나는 첫 번째 것이 명확하고 두 번째라고 생각합니다. 그것은 작은 코드로, 지침을 닫는의 느낌을 코드가 복잡해 잘입니다 제공 {...}이 경우에도 많은 도움이 endif또는begin...end

//first
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}


//second
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

끝났 으면 포인터를 NULL로 설정하는 것이 가장 좋습니다.

이유는 다음과 같습니다.

클래스 A는 다음을 수행합니다.

1. 메모리 블록 할당
2. 그런 다음 얼마 후이 메모리 블록을 삭제하지만 포인터를 NULL로 설정하지 않습니다.

클래스 B는 다음을 수행합니다.

1. 메모리를 할당합니다 (이 경우 클래스 A에 의해 삭제 된 것과 동일한 메모리 블록이 제공됩니다).

이 시점에서 클래스 A와 클래스 B 모두 동일한 메모리 블록을 가리키는 포인터를 가지고 있습니다. 클래스 A와 관련하여이 메모리 블록은 끝나기 때문에 존재하지 않습니다.

다음 문제를 고려하십시오.

클래스 A에 로직 오류가 발생하여 클래스 B에 속하는 메모리에 쓰는 결과는 어떻습니까?

이 특정 인스턴스에서는 메모리 주소가 합법적이므로 클래스 A가 클래스 B 데이터를 효과적으로 손상시키기 때문에 잘못된 액세스 예외 오류가 발생하지 않습니다.

예상치 못한 값이 발생하면 클래스 B가 충돌 할 수 있으며 충돌이 발생하면 문제가 클래스 A에있을 때 클래스 B에서이 버그를 사냥하는 데 오랜 시간이 걸립니다.

삭제 된 메모리 포인터를 NULL로 설정 한 경우 클래스 A의 논리 오류가 NULL 포인터에 쓰려고하면 예외 오류가 발생합니다.

포인터가 두 번째로 NULL 일 때 이중 삭제로 인한 논리 오류가 걱정되는 경우이를 위해 assert를 추가하십시오.

또한 : 투표를 중단하려는 경우 설명하십시오.

항상 중괄호를 사용하는 것은 매우 간단하고 강력한 규칙입니다. 그러나 중괄호가 많으면 코드가 우아하지 않을 수 있습니다. 규칙에서 중괄호를 생략 할 수 있으면보다 자세한 스타일 규칙과보다 정교한 도구가 있어야합니다. 그렇지 않으면 혼란스럽고 혼란스러운 (우아하지 않은) 코드가 쉽게 발생할 수 있습니다. 따라서 다른 스타일 가이드 및 도구와 별도로 단일 스타일 규칙을 사용하는 것은 효과가 없습니다. 나는 다른 답변에서 언급되지 않은 규칙 # 3에 대한 중요한 세부 정보를 가져올 것입니다.

첫 번째 흥미로운 세부 사항은 해당 규칙의 대부분의 지지자들이의 경우이를 위반할 것에 동의한다는 것입니다 else. 다시 말해 그들은 그러한 코드를 검토 할 것을 요구하지 않습니다.

// pedantic rule #3
if ( command == Eat )
{
    eat();
}
else
{
    if ( command == Sleep )
    {
        sleep();
    }
    else
    {
        if ( command == Drink )
        {
            drink();
        }
        else
        {
            complain_about_unknown_command();
        }
    }
}

대신, 그들이 그것을 보면 그들은 다음과 같이 작성하도록 제안 할 수도 있습니다.

// not fully conforming to rule #3
if ( command == Eat )
{
    eat();
}
else if ( command == Sleep )
{
    sleep();
}
else if ( command == Drink )
{
    drink();
}
else
{
   complain_about_unknown_command();
}

else와 사이에 중괄호가 없으므로 기술적으로 해당 규칙을 위반하는 것입니다 if. 이러한 규칙의 이중성은 규칙없는 도구를 사용하여 코드베이스에 자동으로 적용하려고 할 때 발생합니다. 실제로 논쟁의 여지가있는 이유는 도구가 자동으로 스타일을 적용하도록하는 것입니다.

두 번째 세부 사항 (이 규칙의 지지자들이 종종 잊어 버리는 경우도 있음)은 발생할 수있는 오류가 해당 규칙 # 3을 위반 한 경우에만 발생하지 않는다는 것입니다. 실제로는 거의 항상 규칙 # 1 위반을 수반합니다 (아무도 논쟁하지 않습니다). 자동 도구의 ​​관점에서 다시 한 번, 규칙 # 1을 위반하면 즉시 불만을 제기하는 도구를 만드는 것이 어렵지 않으므로 대부분의 오류를 적시에 잡을 수 있습니다.

세 번째 세부 사항 (이 규칙의 반대자들이 종종 잊어 버리는 것)은 단일 세미콜론으로 표시되는 빈 명령문의 혼란스러운 특성입니다. 약간의 경험이있는 대부분의 개발자는 단독으로 세미콜론을 잘못 사용하거나 단독 세미콜론을 사용하여 작성된 빈 문장으로 인해 조만간 혼란스러워졌습니다. 단일 세미콜론 대신 두 개의 중괄호가 시각적으로 쉽게 발견됩니다.

나는 항상 {}한 줄에 사용하는 것은 아니라는 것을 인정해야 하지만 좋은 연습입니다.

• 다음과 같이 대괄호없이 코드를 작성한다고 가정 해 보겠습니다.

  for (int i = 0; i <100; ++ i) for (int j = 0; j <100; ++ j) DoSingleStuff ();

그리고 얼마 후에 j다른 루프 를 추가하고 싶을 때 정렬을 통해 브래킷을 추가하는 것을 잊어 버립니다.

• 메모리 할당 해제가 더 빠릅니다. 범위가 넓고 내부에 큰 배열을 생성한다고 가정 해 봅시다 ( new스택 하지 않고 ). 해당 배열은 범위를 벗어난 직후 메모리에서 제거됩니다. 그러나 해당 배열을 한 곳에서 사용할 수 있으며 잠시 동안 스택 상태가되어 일종의 쓰레기가 될 수 있습니다. 스택이 제한적이고 크기가 작기 때문에 스택 크기를 초과 할 수 있습니다. 그래서 어떤 경우에는 그것을 {}막기 위해 글 을 쓰는 것이 좋습니다 . 참고 이것은 한 줄이 아니라 그러한 상황에 대한 것입니다.

  if (...) {// SomeStuff ... {// 우리는 if, while 등이 없습니다. // SomeOtherStuff} // SomeMoreStuff}

• 그것을 사용하는 세 번째 방법은 두 번째와 비슷합니다. 스택을 깨끗하게 만드는 것이 아니라 일부 기능 을 여는 것입니다. mutex긴 기능 을 사용하는 경우 일반적으로 데이터에 액세스하기 직전과 읽기 / 쓰기를 마친 직후에 잠금 및 잠금 해제하는 것이 좋습니다. 참고 일부 자신이 있으면이 방법은 사용 class또는 struct과 constructor및 destructor잠금 메모리.

• 더 많은 것 :

  if (...) if (...) SomeStuff (); else SomeOtherStuff (); // 두 번째로 넘어가지만, 악어가 첫 번째임을 보여줍니다 ...

나는 {}한 줄 에 항상 사용하는 가장 좋은 방법은 무엇인지 말할 수는 없지만 그렇게하는 것은 나쁘지 않습니다.

중요 편집 한 줄에 대해 컴파일 코드 괄호를 쓰면 아무 것도 수행하지 않지만 코드가 해석되면 코드 속도가 약간 느려집니다. 아주 약간.

제어문을 작성하는 방법에는 여러 가지가 있습니다. 특정 조합은 가독성을 손상시키지 않고 공존 할 수 있지만 다른 조합은 문제를 일으킬 수 있습니다. 스타일

if (condition)
  statement;

제어문을 작성하는 다른 방법 들과는 편안하게 공존 할 수 있지만 다른 방법 들과는 잘 어울리지 않습니다. 여러 줄로 된 제어문이 다음과 같이 작성된 경우 :

if (condition)
{
  statement;
  statement;
}

그러면 어떤 if문장이 한 줄을 제어하고 어떤 문장이 여러 줄을 제어하는지 시각적으로 알 수 있습니다. 그러나 여러 줄로 된 if문장이 다음과 같이 작성된 경우 :

if (condition) {
  statement;
  statement;
}

그러면 if필요한 괄호를 추가하지 않고 단일 문 구조 를 확장하려는 사람이있을 가능성 이 훨씬 높습니다.

if코드베이스가 양식을 많이 사용하는 경우 단일 명령문 다음 행 명령문도 문제가 될 수 있습니다.

if (condition) statement;

저 자신의 선호는 문장을 자체 라인에두면 if비슷한 제어 블록을 가진 문장 이 많은 경우를 제외하고는 일반적으로 가독성을 향상시키는 것입니다.

if (x1 > xmax) x1 = xmax;
if (x1 < xmin) x1 = xmin;
if (x2 > xmax) x2 = xmax;
if (x2 < xmin) x2 = xmin;
etc.

이 경우 일반적으로 이러한 if문장 그룹을 빈 줄로 시작하여 다른 코드와 시각적으로 구분합니다. 모두 if동일한 들여 쓰기로 시작하는 다양한 문장을 갖는 것은 비정상적인 것이 있다는 명확한 시각적 표시를 제공합니다.