“if (0 == value)…”가 좋은 것보다 더 많은 해를 끼치 지 않습니까? [닫은]

이것은 내가 다른 사람의 코드에서 볼 때 가장 싫어하는 것 중 하나입니다. 나는 그것이 무엇을 의미하는지, 왜 어떤 사람들은 이런 식으로 그것을 하는지를 알고 있습니다 ( "실수로 '='를 대신 사용하면 어떻게됩니까?"). 나를 위해 아이가 계단을 내려갈 때 계단을 크게 세는 것과 매우 흡사합니다.

어쨌든, 여기에 대한 나의 주장은 다음과 같습니다.

• 프로그램 코드를 읽는 자연스러운 흐름을 방해합니다. 우리 인간은 "값이 0 인 경우"가 아니라 "값이 0 인 경우"라고 말합니다.
• 현대 컴파일러는 조건에 할당이 있거나 실제로 조건이 해당 할당으로 구성된 경우 경고합니다.
• 프로그래머라면 값을 비교할 때 double '='을 넣는 것을 잊지 마십시오. "!"를 넣는 것을 잊어 버릴 수도 있습니다. 비평 등을 테스트 할 때

아, 그렇습니다. "요다 조건부"( "값이 0이면이 코드를 실행하십시오!"). 나는 항상 그들이 lint (1)와 같은 도구에 대해 더 낫다고 주장하는 사람을 지적합니다. 이 특정 문제는 70 년대 후반부터 해결되었습니다. 대부분의 현대 언어는 if(x = 10)부울에 할당 한 결과를 강제로 거부하기 때문에 와 같은 표현식을 컴파일조차하지 않습니다 .

다른 사람들이 말했듯이, 그것은 확실히 문제가 아니지만 약간의인지 부조화를 유발합니다.

그것은 작지만 눈에 띄는 정신 세를 부과하기 때문에 불쾌합니다.

사람들은 거의 모든 프로그래밍 언어 (및 대부분의 자연어)에서 왼쪽에서 오른쪽으로 읽습니다.

내가 볼 때 123 == x, 정신적으로 분석하는 방식은 다음과 같습니다.

• 123-그래서 뭐? 불완전한 정보.
• == -123은 123입니다. 왜 테스트합니까?
• x-그래, 우리가 걱정하는 부분이야. 지금 만 상황이 있습니다.
• 다시 재고로 돌아가서 123x와 비교하는 이유.

내가 볼 때 x == 123정신 분석은 다음과 같습니다

• x-상황을 제공하며 조건에 대해 알고 있습니다. 나머지는 무시해도됩니다. 이전 흐름을 기반으로 나는 왜 그리고 앞으로 올 것이 무엇인지 (그리고 그것이 다르다면 놀랐습니다) 좋은 아이디어를 얻었습니다.
• == -나도 그렇게 생각해
• 123 -응

중단은 작지만 (단순한 예에서는) 항상 눈치 notice습니다.

당신이 경우 먼저 값을 두는 것은 좋은 생각이있을 수 있습니다 원하는 예를 들어, 그것에 관심을 끌기 위해 if (LAUNCH_NUKES == cmd). 일반적으로 이것은 의도가 아닙니다.

해로운? 아니요. 어느 쪽이든 작동합니다.

나쁜 연습? 물론 논쟁의 여지가 있습니다. 간단한 방어 프로그래밍입니다.

잠을 잃을 가치가 있습니까? 아냐

이것은 기본적으로 flaimbait입니다.

아닙니다. 선보다 해를 끼치 지 않습니다. 단순한.

더 많은 단어?

컴파일러 논쟁? 어머, 어쩌면-어쩌면 당신을 구하기 위해 컴파일러에 너무 많은 믿음을 두지 마십시오.

잘 - "당신은 잊지 말아야" 대만족 걸, 아니 물론 당신이 그 사이에 내가 피곤, 나는 두 개의 서로 다른 언어를 사용했다 때로는 단지 가끔 한 모든 일을 코딩 봤는데있어 안되는 인간 - 실수.

이런 종류의 행동의 요점은 방어 적이라는 것입니다. 충돌을 예상하기 때문에 보험보다 더 실수를 할 것으로 예상되기 때문입니다. 그러나 보험에 가입하면 좋을 것입니다.

읽기 어려운가요? 당신은 괜찮은 프로그래머가 == 고정 배선을해야한다고 주장하지만 (모든 종류의 나쁜 가정을합니다) 자기 같은 괜찮은 프로그래머는 0 == value를 읽을 수 없습니다 ??

해를 끼치 지 않으며 잠재적 이점이 있으며 어리석은 질문이며 다른 사람들이 원하면 계속 할 수 있습니다.

나는 그것을 해로 부르지 않을 것이지만, 그것은 불쾌합니다. 그래서 나는 그렇게 말하지 않을 것입니다.

나는 '전체를 잊어 버리면 어떻게 될까?' 정말 많은 무게를 가졌습니다. 예, 오타를 만들 수 있지만 오타는 모두 실수입니다. 실수를 두려워하기 때문에 전체 코딩 스타일을 변경하는 것은 어리석은 것 같습니다. 언젠가 무언가를 대문자로 쓰거나 밑줄을 잊어 버릴 수 있기 때문에 모든 변수와 함수를 펑크없이 소문자로 만드십시오.

일부 사람들은 조건부 작업을 정확하게하기 위해이 도구를 사용합니다. 예를 들어 :

방법 1 :

FILE *fp;

fp = fopen("foo.txt", "w+");
if (fp == NULL) {

방법 2 :

FILE *fp;

if (NULL == (fp = fopen("foo.txt", "w+"))) {

어떤 사람들은 두 번째 예가 더 간결하다고 생각하거나 역전 된 주장은 시험 자체 이전의 시험 (조건부)의 요점을 보여줍니다.

실제로, 나는 정말로 어느 쪽도 상관하지 않습니다. 나는 스타일에 대한 나의 애완 동물 친구들을 가지고 있으며 가장 큰 것은 불일치입니다. 따라서 동일한 방식으로 일관되게 수행하면 코드를 읽지 않아도됩니다.

자신의 독특한 스타일로 한 번에 6 명의 다른 사람들이 한 번에 작동하는 것처럼 보일 때까지 조금 혼란 스럽습니다.

나에게 그것은 간단한 컨디셔닝입니다. (90 년대에) C와 C ++을 배운 사람으로서, 나는 그 이유가 교훈이 되더라도 그것에 익숙해 져서 여전히 그것을 사용합니다.

"일정한"에 대해 왼쪽을 보도록 "조절 된"상태가되면 두 번째 특성이됩니다.

또한 동등성 (또는 부정적 동등성)에 대해서만 사용합니다.

@Wonko의 답변에 전적으로 동의합니다.

내가 도움이되는 한 가지 경우는 if의 변수 부분이 꽤 길고 값을 보면 코드를 쉽게 읽을 수 있습니다. 점으로 구분 된 네임 스페이스 언어에 가장 적합한 예가 있습니다.

예를 들어, 싱글 사인온 (SSO)으로 작업 한 무언가에 특정 유형의 오류가 발생하고 특정 방식으로 복구 된 경우 두 개의 동시 세션이있을 수있는 상황이 발생했습니다. 이 같은:

if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())

이 예제에는 다른 방법이 있지만, 첫 번째 버전이 더 읽기 쉬운 경우가 있습니다.

그러나 오류가 발생합니다. 때로는 루프 연산자를 사용하여 동등성을 검사 할 수도 있고 적어도 표준을 사용하는 것이 좋습니다.

내가 따랐던 조언 (아마도 Code Complete)은 왼쪽에서 가장 낮은 값을 비교하는 것입니다. 나는 이전에 동료와이 문제를 논의하고 있었는데, 그는 그것이 미쳤다고 생각했지만 나는 그것에 매우 익숙해졌다.

그래서 나는 말할 것입니다 :

if ( 0 <= value )

그러나 나는 또한 말할 것입니다 :

if ( value <= 100 )

평등 왼쪽에있는 변수를 확인하는 경향이 있습니다. 더 읽기 쉽습니다.