필요하지 않은 경우에도 논리 문에 괄호를 사용해야합니까?

부울 조건 이 있고보다 우선 순위가 높은 a AND b OR c AND d언어를 사용 한다고 가정 해 봅시다 . 이 코드 줄을 작성할 수 있습니다.ANDOR

If (a AND b) OR (c AND d) Then ...

그러나 실제로는 다음과 같습니다.

If a AND b OR c AND d Then ...

관련없는 괄호를 포함하거나 반대하는 주장이 있습니까? 실제 경험에 의하면 가독성을 위해 그것들을 포함시킬 가치가 있다고 제안합니까? 아니면 개발자가 진정으로 언어의 기초에 대해 자신감을 가져야한다는 신호입니까?

좋은 개발자는 명확 하고 올바른 코드를 작성하려고 노력 합니다 . 조건부 괄호는 엄격하게 요구되지 않더라도 둘 다에 도움이됩니다.

명확성을 위해 괄호는 코드의 주석과 같이 생각하십시오. 꼭 필요한 것은 아니며 이론적으로 유능한 개발자는 코드없이 코드를 알아낼 수 있어야합니다. 그러나이 단서는 다음과 같은 이유로 매우 유용합니다.

• 코드를 이해하는 데 필요한 작업이 줄어 듭니다.
• 개발자의 의도를 확인합니다.

또한 들여 쓰기, 공백 및 기타 스타일 표준과 같이 추가 괄호는 코드를 논리적으로 시각적으로 구성하는 데 도움이됩니다.

에 관해서는 정확성 , 괄호가없는 조건은 어리석은 실수를위한 조리법이다. 이러한 상황이 발생하면 찾기 어려운 버그 일 수 있습니다. 종종 잘못된 조건이 대부분 올바르게 작동하고 가끔 실패하기 때문입니다.

그리고 올바르게 이해하더라도 다음 코드 작성 담당자는 표현식에 오류를 추가하거나 논리를 이해하지 못하여 다른 곳에 오류를 추가 할 수 없습니다 (LarsH가 올바르게 지적한대로).

나는 항상 결합 and하고 or(우선 순위가 비슷한 유사한 산술 연산) 표현식에 괄호를 사용 합니다.

그것은 덜 여부 문제 는 언어의 당신의 이해에 확신합니다. 더 중요한 것은 당신을 따르는 n00b의 언어를 이해하는 것입니다.

가장 명확하고 명확한 방법으로 코드를 작성하십시오. 추가 괄호는 종종 (항상 그런 것은 아님) 도움이됩니다. 한 줄에 한 줄만 쓰면 도움이됩니다. 코딩 스타일의 일관성은 종종 도움이됩니다.

괄호가 너무 많지만 조언이 필요하지 않은 상황 중 하나입니다. 볼 때 알 수 있습니다. 이 시점에서 코드를 리팩터링하여 괄호를 제거하지 않고 명령문의 복잡성을 줄입니다.

예

항상 괄호를 사용해야합니다 ... 우선 순위를 제어하지 않습니다 ... 컴파일러 개발자가합니다. 괄호를 사용하지 않는 것에 대해 나에게 일어난 이야기가 있습니다. 이는 2 주 동안 수백 명의 사람들에게 영향을 미쳤습니다.

실제 이유

메인 프레임 응용 프로그램을 상속했습니다. 어느 날, 청록색에서 작동이 멈췄습니다. 그게 다야 .. 멈 췄어.

내 직업은 가능한 빨리 작동시키는 것이 었습니다. 소스 코드는 2 년 동안 수정되지 않았지만 갑자기 중단되었습니다. 코드를 컴파일하려고했는데 XX 줄에서 끊어졌습니다. XX 행을 보았는데 XX 행을 중단시킬 항목을 알 수 없었습니다. 이 응용 프로그램에 대한 자세한 사양을 요청했지만 아무것도 없었습니다. XX 행은 범인이 아니 었습니다.

코드를 인쇄하여 위에서 아래로 검토하기 시작했습니다. 나는 무슨 일이 일어나고 있는지에 대한 순서도를 만들기 시작했습니다. 코드는 너무 복잡해서 이해가 거의되지 않았습니다. 나는 순서도를 포기하려고 포기했다. 특히 응용 프로그램이 수행 한 작업이나 종속성 체인의 위치에 대한 세부 정보가 없기 때문에 해당 변경 사항이 프로세스의 나머지 프로세스에 어떤 영향을 미치는지 알지 못한 채 변경하기를 두려워했습니다.

그래서 소스 코드 맨 위에서 시작하여 코드를 더 읽기 쉽게하기 위해 whitespce와 line 브레이크를 추가하기로 결정했습니다. 어떤 경우에는 어떤 조건이 결합 AND되었고 OR어떤 데이터가 AND어떤 데이터와 어떤 데이터가 구별되고 있는지 명확하게 구분되지 않는 경우가 있음을 알게되었습니다 OR. 그래서 나는 더 읽기 쉽게하기 위해 ANDand 주위에 괄호를두기 시작했습니다 OR.

청소를 천천히 진행하면서 정기적으로 작업을 저장했습니다. 어느 시점에서 나는 코드를 컴파일하려고 시도했고 이상한 일이 일어났다. 오류가 코드의 원래 줄을 넘어서서 더 이상 내려갔습니다. 그래서 나는 계속해서, AND그리고 OR조건을 parens로 분리했습니다. 청소가 끝나면 효과가있었습니다. 그림을 이동.

그런 다음 운영 상점을 방문하여 최근에 메인 프레임에 새로운 구성 요소를 설치했는지 물어보기로 결정했습니다. 예, 우리는 최근에 컴파일러를 업그레이드했습니다. 흠.

이전 컴파일러는 관계없이 왼쪽에서 오른쪽으로 식을 평가했습니다. 컴파일러의 새로운 버전은 또한 불분명 조합을 의미를 잘하지만, 모호한 코드 왼쪽에서 식을 평가 AND하고 OR분석 할 수 없습니다입니다.

내가 배운 교훈은 ... 항상, 항상, 서로 결합하여 사용될 때 항상 AND조건 을 분리하기 위해 Parens를 OR사용합니다.

단순화 된 예

IF Product = 191 OR Product = 193 AND Model = "ABC" OR Product = 201 OR Product = 202 AND Model = "DEF" ...(여러 코드로 흩어진 코드)

이것은 내가 만난 것의 단순화 된 버전입니다. 복합 부울 논리 문이있는 조건도있었습니다.

나는 그것을 추격하는 것을 기억한다.
IF ((Product = 191 OR Product = 193) AND Model = "ABC") OR ((Product = 201 OR Product = 202) AND Model = "DEF") ...

사양이 없어서 다시 쓸 수 없었습니다. 원래의 저자는 오랫동안 사라졌습니다. 나는 강한 압력을 기억합니다. 전체 화물선이 항구에 좌초되어이 작은 프로그램이 작동하지 않아서 하역 할 수 없었습니다. 경고가 없습니다. 소스 코드가 변경되지 않았습니다. Parens를 추가하면 오류가 이동 한 것을 발견 한 후 네트워크 작업에서 수정 한 것이 있는지 물어 보았습니다.

예, 'and'와 'or'가 혼합되어 있다면 가능합니다.

또한 논리적으로 하나의 검사가 무엇인지에 대한 좋은 아이디어입니다.

가장 좋은 방법은 잘 알려진 술어 함수를 사용하고 대부분의 점검 및 조건을 제거하는 것입니다.

괄호는 의미 적으로 중복되므로 컴파일러는 신경 쓰지 않지만 붉은 청어입니다. 진정한 관심사는 프로그래머의 가독성과 이해입니다.

나는 여기서 과격한 입장을 취하고의 괄호에 진지한 "아니오"를 줄 것이다 a AND b OR c AND d. 모든 프로그래머는 부울 표현식에서 우선 순위가가는 그 마음으로 알아야 할 NOT> AND> OR 단지 기억처럼, 나의 친애하는 이모 샐리 실례 대수 표현식. 중복 구두점은 프로그래머가 읽을 수있는 이점없이 코드에 시각적 혼란을 더해줍니다.

또한 논리 및 대수 표현에 항상 괄호를 사용하면 "어딘가 까다로운 일이 있습니다. 조심하십시오"라는 표시로 사용할 수 있습니다. 즉, 기본 우선 순위 를 재정의 하고 곱하기 전에 또는 OR 전에 AND를 평가 하려는 경우 괄호는 다음 프로그래머에게 좋은 신호입니다. 필요하지 않을 때 너무 많이 사용하면 늑대를 부르는 소년이됩니다.

나는 C의 포인터 표현과 같이 대수 영역 (부울 또는 그렇지 않음) 외부의 것을 제외 하고 역 참조와 산술을 똑바로 유지하기 위해 표준 관용구보다 복잡한 것이 *p++있거나 p = p->next괄호로 묶어야합니다. 물론 Lisp, Forth 또는 Smalltalk와 같은 언어 표기법을 표현에 사용하는 언어에는이 중 어느 것도 적용되지 않습니다. 그러나 대부분의 주류 언어의 경우 논리 및 산술 우선 순위가 완전히 표준화됩니다.

내가 본대로 :

예, 장점 :

• 작업 순서는 명시 적입니다.
• 작업 순서를 이해하지 못하는 미래 개발자로부터 보호합니다.

예 단점 :

• 혼란스럽고 읽기 어려운 코드가 발생할 수 있음

NO 장점 없습니다 :

• ?

NO 단점 없습니다 :

• 작업 순서는 암시 적
• 작업 순서를 잘 이해하지 못하면 개발자가 코드를 유지 관리하기가 쉽지 않습니다.

관련없는 괄호를 포함하거나 반대하는 주장이 있습니까? 실제 경험에 의하면 가독성을 위해 그것들을 포함시킬 가치가 있다고 제안합니까? 아니면 개발자가 진정으로 언어의 기초에 대해 자신감을 가져야한다는 신호입니까?

다른 사람이 내 코드를 다시 볼 필요가 없다면 신경 쓰지 않을 것입니다.

그러나 내 경험에서 :

• 내 코드를 때때로 다시 본다 (때로는 몇 년이 지난 후)
• 다른 사람들은 때때로 내 코드를 봅니다.
  • 또는 확장하거나 수정해야합니다!
• 나 자신이나 다른 사람이 내가 쓸 때 생각했던 것을 정확하게 기억하지 못한다
• 암호 문자를 최소화하는 암호를 작성하면 가독성이 떨어집니다.

나는 거의 항상 이것을한다. 왜냐하면 나는 다른 어떤 것보다 빨리 읽고, 작은 실수를 많이하지 않는 나의 능력을 신뢰하기 때문이다.

귀하의 경우 거의 확실하게 다음과 같은 작업을 수행합니다.

if (a AND b) then ab = true
if (c AND d) then cd = true
If (ab OR cd) Then ...

예, 더 많은 코드입니다. 예, 대신 멋진 부울 연산자를 사용할 수 있습니다. 아니요, 앞으로 1 년 이상 코드를 감추고 멋진 부울 연산자를 잘못 읽을 가능성이 마음에 들지 않습니다. AND / OR 우선 순위가 다른 언어로 코드를 작성하고이 문제를 해결하기 위해 뒤로 건너 뛰었다면 어떻게합니까? "아하! 나는 내가 한이 영리한 작은 일을 기억한다! 나는 작년에 글을 쓸 때 파 렌스를 포함시킬 필요가 없었다. 지금 기억하고있는 것은 좋은 일이다!" 그런 일이 발생하면 (혹은이 영리함을 알지 못했거나 "수정 가능한 빨리"유형의 상황에 처한 다른 사람)?

()로 구분하면 나중에 빠르게 탈지하고 이해하는 것이 훨씬 간단합니다 ...

일반적인 경우

C #에서 곱셈과 나눗셈은 덧셈과 뺄셈보다 우선합니다.

그럼에도 불구하고 코드베이스 전체에 공통 스타일을 적용하는 도구 인 StyleCop은 코드로 인해 명확하지 않을 수도있는 버그의 위험을 완화하기위한 SA1407 규칙을 따릅니다 . 이 규칙은 다음과 같은 코드로 경고를 생성합니다.

var a = 1 + 2 * 3;

StyleCop은 결과가 7이고 그렇지 않다는 것이 분명 9하지만 여전히 괄호를 넣을 것을 제안합니다.

var a = 1 + (2 * 3);

당신의 특별한 경우

특정한 경우에는 사용하는 특정 언어에서 AND와 OR보다 우선 순위가 높습니다.

이것이 모든 언어의 행동 방식은 아닙니다. 많은 사람들이 AND와 OR을 동등하게 취급합니다.

C #을 주로 사용하는 개발자로서, 처음 질문을보고 이전에 작성한 내용을 읽지 않고 코드를 읽을 때 첫 번째 유혹은 두 표현이 동일하지 않다는 의견이었습니다. 바라건대, 나는 주석을 달기 전에 전체 질문을 완전히 읽었습니다.

이 특수성과 일부 개발자가 AND 및 OR의 우선 순위가 같다고 믿기 때문에 괄호를 추가하는 것이 더욱 중요합니다.

당신이 똑똑하다는 것을 보여주기 위해 코드를 작성하지 마십시오. 언어의 모든 측면에 익숙하지 않은 사람들을 포함하여 가독성을 목표로 코드를 작성하십시오.

모든 사람들이 말했듯이 표현을 더 읽기 쉽게 만들 때마다 괄호를 사용하십시오. 그러나 표현식이 복잡 하면 하위 표현식에 새로운 함수 를 도입하는 것이 좋습니다.

아니면 개발자가 진정으로 언어의 기초에 대해 자신감을 가져야한다는 신호입니까?

언어 를 단수로 엄격하게 사용한다면 어쩌면. 이제 이전부터 현대에 이르기까지, 컴파일에서 스크립팅, SQL, 지난 달에 개발 한 DSL에 이르기까지 모든 언어 를 사용하십시오.

보지 않고 각 언어에 대한 정확한 우선 순위 규칙을 기억하십니까?

"필요하지 않은 경우에도 논리 문에 괄호를 사용해야합니까?"

두 사람이 도움이 될 것이기 때문에 그렇습니다.

• 지식, 역량 또는 스타일을 가진 다음 프로그래머는 다를 수 있습니다

• 나중에이 코드로 돌아 오는 미래!

당신이, 음, 정확히 대수와 같은 꽤 많이 보이게 어떤 방법으로 작성하고, 당신은 확실히위한 괄호 사용하십시오 복잡한 조건문 "부울 대수가"있다가, 대수학 , 당신이하지 않을까요?

정말 유용한 규칙은 부정 규칙입니다.

!(A || B) <=> !A && !B
!(A && B) <=> !A || !B

또는 좀 더 명확한 형식으로 :

!(A + B) <=> !A * !B
!(A * B) <=> !A + !B

이것은 다음과 같이 쓸 때 실제로 대수적입니다.

-1*(A + B) = -A + -B
-1*(A * B) = -A * -B

그러나 대수 단순화 및 확장에 대한 생각을 적용 할 수도 있습니다.

(A && B) || (C && D) => 
((A && B) || C) && ((A && B) || D) => 
(AC && BC) && (AD && BD) =>
AC && BC && AD && BD

코드에서는 다음과 같이 작성해야합니다.

(A||C) && (B||C) && (A||D) && (B||D)

또는 좀 더 명확한 형식으로 :

(A + B) * (C + D) => 
((A + B) * C) + ((A + B) * D) => 
(AC + BC) + (AD + BD) =>
AC + BC + AD + BD

기본적으로 조건은 여전히 ​​대수적 표현이며 괄호를 명확하게 사용하면 "이 공식을 단순화 또는 확장"이라는 오래된 개념을 포함하여 이미 알고있는 다양한 대수 규칙을 표현에 더 쉽게 적용 할 수 있습니다.

선택 사항 인 경우에도 괄호를 사용합니다. 코드를 작성하는 사람과 해당 코드를 볼 준비가 된 사람 모두를 위해 더 잘 이해하는 데 도움이되는 이유는 무엇입니까? 귀하의 경우 부울 연산자조차도 처음에는 잘 작동 할 수있는 우선 순위가 있지만 모든 경우에 도움이 될 것이라고 말할 수는 없습니다. 그래서 나는 그것이 필요하거나 선택적으로 필요한 조건에서 사용자 괄호를 선호합니다.

예. 코드가 더 명확하다고 생각되는 경우에 사용해야합니다. 코드 내에서 주석을 읽지 않고 다른 사람들이 이해할 수 있도록 코드가 명확해야합니다. 따라서 괄호와 중괄호를 사용하는 것이 좋습니다. 또한 회사 / 팀의 특정 관행에 따라 달라질 수 있습니다. 한 가지 접근 방식 만 유지하고 혼합하지 마십시오.