유료 콘텐츠를 참조하는 것이 싫지만 이 비디오 는 내가 말하는 내용을 정확하게 보여줍니다. Robert Martin에서 정확히 12 분은 다음과 같습니다.

"내가 가장 좋아하는 일 중 하나는 쓸모없는 괄호를 없애는 것"이라고 말합니다.

오래 전에, 멀리 떨어진 교육에서 나는 그렇지 않은 if경우에 의해 제어되는 다른 들여 쓰기 된 줄을 추가하여 버그를 쉽게 도입 할 수 있기 때문에 이것을하지 말라고 배웠습니다 .

밥 아저씨에게 공평하게, 그는 긴 Java 메소드를 아주 작은 함수로 리팩토링하고 있습니다. 그가 변경을 마치면 (22.18) 다음과 같이 보입니다.

그것이 괄호 제거의 유효성을 검사 해야하는지 궁금합니다. 이미 모범 사례에 익숙 합니다 . 이 시점에서 Bob 아저씨에게 도전 할 수 있습니까? 밥 아저씨가이 아이디어를 변호 했습니까?

가독성은 작은 것이 아닙니다.

단일 방법을 묶는 중괄호와 관련하여 혼합 된 마음입니다. 나는 한 줄 반환 진술과 같은 것들을 개인적으로 제거하지만 그러한 괄호를 없애면 실제로 내가 일했던 마지막 장소에서 우리를 매우 열심히 물었습니다. 누군가 if필요한 괄호를 추가하지 않고 명령문 에 코드 줄을 추가했으며 C이므로 경고없이 시스템을 중단했습니다.

나는 그 작은 실패 이후에 항상 중괄호를 사용하는 것에 대해 종교적인 사람에게 도전하지 않습니다.

따라서 가독성의 이점을 볼 수 있지만 이러한 중괄호를 제거 할 때 발생할 수있는 문제를 예리하게 알고 있습니다.

나는 연구 나 다른 사람의 발표 된 의견을 찾으려고 노력하지 않을 것입니다. 모든 사람은 하나의 의견 (즉, 의견)을 갖고 있으며 문체 문제이기 때문에 하나의 의견은 다른 의견만큼이나 좋습니다. 문제를 스스로 생각하고 장단점을 평가하며 자신의 저주받은 마음을 만드십시오. 작업하는 상점에이 문제를 다루는 코딩 표준이있는 경우 해당 표준을 따르십시오.

여기 또는 여기 또는 자전거 창고가 페인트되어있는 곳 어디에서나 버팀목없는 스타일의 판촉 또는 거부 된 여러 출판물을 찾을 수 있습니다 .

자전거 창고에서 벗어나 2014 년의 위대한 OS X / iOS SSL 버그를 기억하십니까?

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

괄호가없는 블록으로 인한 "원인" https://www.imperialviolet.org/2014/02/22/applebug.html

기본 설정은 가새 스타일에 따라 달라질 수 있습니다. 내가 써야한다면

if (suiteSetup)
{
    includePage(mode, suiteSetup);
}

공간을 절약하려는 경향이 있습니다. 그러나

if (suiteSetup) {
    includePage(mode, suiteSetup);
}

하나의 "추가"라인 만 사용합니다.

나는 당신이 묻지 않았다는 것을 알고 있지만, 혼자 일하고 있다면 나는 이단자입니다. 중괄호를 제거하면 선호합니다

if (suiteSetup != null) includePage(mode, suiteSetup);

iOS SSL 스타일 버그와 동일한 시각적 문제는 없지만 Bob 아저씨보다 "필요하지 않은"줄을 더 많이 절약 includePage(mode, suiteSetup) unless suiteSetup.nil?합니다. 글쎄, 단지 의견이 많다는 것을 알고 있습니다.

Bob 아저씨는 "항상 괄호 사용"이 일반적인 지혜 였을 때 흔한 일이 아니었던 그러한 실수에 대해 많은 방어 계층을 가지고 있습니다.

1. 한 줄 조건부 조건에 대한 개인의 선호도가 높기 때문에 여러 줄 조건이 눈에 띄고 추가 검사를받습니다.
2. 두 번째 줄을 삽입 할 때 자동으로 넘어지는 편집기입니다.
3. 그가 지속적으로 실행하는 완전한 단위 테스트 세트.
4. 완전한 통합 테스트 스위트.
5. 그의 코드가 병합되기 전에 수행 된 동료 검토.
6. 지속적인 통합 서버에 의한 모든 테스트의 재실행.
7. 제품 품질 부서에서 수행 한 테스트

누군가 Bob 아저씨에게 도전을 게시했다면 위의 요점에 대해 꽤 반박 할 것입니다. 이것은 일찍 잡는 가장 쉬운 실수 중 하나입니다.

대부분의 경우 이것은 개인적인 취향이지만 고려해야 할 사항이 있습니다.

가능한 버그

이 추가 기능에 괄호를 잊고에 의한 버그 내가 한 것과, 희귀 주장 할 수 있지만 볼 것을 그들이 할 일이 가끔 (유명한 잊지하지 IOS 고토 실패 버그). 따라서 코드 스타일을 고려할 때 이것이 요인이되어야한다고 생각합니다 (일부 도구는 들여 쓰기 에 대해 경고 하므로 도구 체인에 따라 다릅니다) .

유효한 코드 ( 버그 일 수있는 것처럼 읽음 )

프로젝트가 그러한 버그로 고통받지 않는다고 가정하더라도 코드를 읽을 때 버그 가 될 수 있는 것처럼 보이는 코드 블록이 보일 수 있습니다.

우리는 시작합니다 :

if (foo)
    bar();

개발자는 유용한 의견을 추가합니다.

if (foo)
    // At this point we know foo is valid.
    bar();

나중에 개발자가 확장합니다.

if (foo)
    // At this point we know foo is valid.
    // This never fails but is too slow even for debug, so keep disabled.
    // assert(is_valid(foo));
    bar();

또는 중첩 블록을 추가합니다.

if (foo)
    while (i--) {
        bar(i);
        baz(i);
    }

또는 매크로를 사용합니다.

if (foo)
    SOME_MACRO();

"... 매크로가 여러 줄의 코드를 정의 할 수 있기 때문에 매크로가 여러 줄에 사용 do {...} while (0)됩니까? 스타일 가이드에 포함되어 있어야하지만 경우에 따라 더 잘 검사해야합니다!"

위의 예제는 모두 유효한 코드이지만 코드 블록의 내용이 많을수록 실수가 없도록 더 많이 읽을 필요가 있습니다.

코드 스타일에 따라 여러 줄 블록에 코드가 없어도 중괄호가 필요하다고 정의 할 수 있지만 프로덕션 코드에 이러한 종류의 주석이 추가되는 것을 보았습니다. 당신이 그것을 읽을 때, 그 줄을 마지막으로 편집 한 사람이 중괄호를 잊어 버렸다는 의심의 여지가 있습니다. 때로는 다시 확인해야 할 필요성이 의도 한대로 작동한다고 생각합니다 (특히 코드 의이 영역에서 버그를 조사 할 때) .

차음 노이즈

단일 라인에 버팀대를 사용하는 실질적인 이유 중 하나는 확산 노이즈 를 줄이는 것 입니다.

즉, 변경 :

if (foo)
    bar();

에:

if (foo) {
    bar();
    baz();
}

... 조건부 행이 변경 될 때 diff에 나타나게하므로 작지만 불필요한 오버 헤드가 추가됩니다.

• 코드 검토에서 행이 변경된 것으로 표시됩니다. diffing 도구가 단어 기반 인 경우 괄호 만 변경되었음을 쉽게 알 수 있지만 행이 변경되지 않았는지 확인하는 데 시간이 더 걸립니다.
  모든 도구가 단어 기반의 diffing을 지원하는 것은 아니며 diff (svn, git, hg 등)는 멋진 도구를 사용하더라도 전체 줄이 바뀌는 것처럼 보일 것입니다. 때로는 평범한 줄을 빠르게 살펴볼 필요가 있습니다. 변경 내용을 확인하기 위해 기반 diff.
• 주석 도구 (예 git blame:)는 행이 변경된 것으로 표시하므로 행의 원점을 추적하여 실제 변경 을 찾을 수 있습니다.

이것들은 모두 작으며, 변경된 코드 라인을 커밋하는 코드 검토 또는 추적에 소요되는 시간에 달려 있습니다.

diff에서 여분의 라인을 변경하는 데있어 실질적인 불편은 코드의 변경으로 인해 충돌이 발생하여 병합되고 수동으로 해결 해야 할 가능성이 높습니다 .

{자체 라인 이있는 코드베이스에는 예외가 있습니다. 문제는 아닙니다.

은 diff 소음 이 스타일로 작성하는 경우 인수는 보유하지 않습니다

if (foo)
{
    bar();
    baz();
}

그러나 이것은 일반적인 관습이 아니기 때문에 주로 완성도에 대한 답변을 추가합니다 (프로젝트 가이 스타일을 사용해야한다고 제안하지 않음) .

몇 년 전, 나는 C 코드를 디버깅하기 위해 들여왔다. 버그는 찾기가 어려웠지만 결국 다음과 같은 문장으로 요약되었습니다.

if (debug)
   foo (4);

그리고 그것을 쓴 사람 foo은 매크로로 정의되었다는 것이 밝혀졌습니다 . 두 줄의 코드가 있는 매크로입니다 . 물론이 두 줄 중 첫 번째 줄만 if. (따라서 두 번째 줄은 무조건 실행되었습니다.)

이것은 C와 그 전 처리기 (컴파일 전에 대체를 수행하는)에 절대적으로 고유 할 수 있지만, 결코 잊어 버리지 않았습니다. 그런 종류의 일이 당신에게 표시를 남깁니다. 특히 다양한 언어와 툴체인을 사용하고 다른 곳에서 그런 shenanigans가 가능하지 않다고 확신 할 수없는 경우 안전하게 재생하지 않는 이유는 무엇입니까?

이제 다른 사람과 다르게 괄호를 들여 쓰고 사용합니다. 단일 라인의 if경우 다음을 수행합니다.

if (debug) { foo (4); }

괄호를 포함하기 위해 추가 줄이 필요하지 않습니다.

"밥 아저씨"는 그의 의견을 가질 수 있으며, 당신은 당신의 의견을 가질 수 있습니다. 그에게 도전 할 필요가 없습니다.

당국에 항소하려면 Chris Lattner를 선택하십시오. Swift에서 문장이 괄호를 잃어 버렸지 만 항상 중괄호가 있습니다. 토론은 없습니다. 언어의 일부입니다. 따라서 "Uncle Bob"이 중괄호 제거를 시작하면 코드 컴파일이 중지됩니다.

다른 사람의 코드를 살펴보고 "쓸모없는 버팀대를 없애는 것"은 나쁜 습관입니다. 코드를 검토해야하고 충돌이 불필요하게 발생하는 경우에만 추가 작업이 발생합니다. 어쩌면 "Uncle Bob"은 코드 리뷰가 필요없는 믿을 수 없을 정도로 좋은 프로그래머일까요? 최고의 프로그래머 한 명이 코드 검토없이 "if (p! = NULL)"을 "if (! p)"로 변경하여 최악의 장소에 숨겨져 일주일을 낭비했습니다.

이것은 대부분 무해한 스타일의 논쟁입니다. 중괄호는 중괄호를 추가하지 않고 다른 코드 줄을 삽입 할 수 있다는 이점이 있습니다. 로깅 문장 또는 주석과 같이 (설명 다음에 명령문이 오는 경우) 많은 디버거에 문제가 있다는 실질적인 단점이있는 것처럼 같은 줄에 그러나 원하는대로하십시오.

중괄호를 제거하지 않는 이유는 다음과 같습니다.

1. 의사 결정 피로를 줄입니다. 항상 중괄호를 사용하면 중괄호가 필요한지 여부를 결정할 필요가 없습니다.

2. 개발 드래그 감소 : 결국 여러 개의 로직 라인을 메소드 로 추출 하려고 노력하더라도 로직을 추가하는 경우 중괄호로 변환하는 것은 중괄호로 변환해야하는 것은 개발 드래그의 성가신 일입니다. 따라서 괄호를 제거하고 더 많은 코드가 필요할 때 괄호를 다시 추가하는 노력이 있습니다. 작지만 성가시다.

젊은 동료는 우리가 중복적이고 불필요한 것으로 보이는 괄호가 실제로 그에게 도움이된다고 말했습니다. 이유를 정확히 기억하지는 못하지만 더 나은 코드를 더 빨리 작성할 수 있다면 그 자체만으로도이를 유지할 수 있습니다.

FWIW, 우리는 한 줄에 이르렀하는 등 짧은 전제 조건이하지 않는 절충안에 합의 되지 않은 나에게 산만 / 읽을. 예 :

if (!param) { throw invalid_argument (blahblah); }
if (n < 2) { return 0; }
// real code for function starts here...

또한 이러한 입문 전제 조건은 종종 신체에 대한 제어 흐름 문 (예 return:)이므로 동일한 조건하에 있고 중괄호를 쓰는 것을 잊어 버리는 두 번째 문을 추가하는 것에 대한 두려움은 무례합니다. 이 조건 하의 두 번째 진술은 어쨌든 죽은 코드이며 의미가 없습니다.

나는 독서 문제 의 유창함 이 사람의 뇌 파서가 조건 문의 일부로 중괄호를 갖도록 배선되어 있기 때문에 발생한다고 생각합니다. 이는 C ++ 문법의 정확한 표현은 아니지만 다른 언어를 먼저 배우면 부작용이 될 수 있습니다 .

지금 그 비디오를 보았을 때, 중괄호를 제거하면 코드를 리팩터링해야하는 위치를 더 쉽게 확인할 수 있습니다. 중괄호가 필요한 경우 코드가 약간 깨끗할 수 있습니다.

당신이 팀에있을 때 중괄호를 제거하면 언젠가 예기치 않은 동작이 발생할 것이라고 말했습니다. 나는 그들을 지키라고 말하고, 일이 잘못 될 때 많은 두통을 피할 수 있습니다.

나는 그렇지 않은 경우 if에 의해 제어되는 다른 들여 쓰기 된 줄을 추가하여 버그를 쉽게 도입 할 수 있기 때문에 이것을하지 말라고 배웠습니다.

코드가 단위 테스트를 거쳤 다면 이런 종류의 "버그"가 폭발 할 것입니다.

쓸모없고 못생긴 괄호를 피하여 코드를 청소하는 것이 제가 따르는 관행입니다.