== true로 큰 거래를합니까?

끊임없이 쓰는 내 동료가 있습니다.

if (someBool == true)

그것은 나를 벽으로 몰아 넣는다! 내가 그것을 많이해야합니까 아니면 그냥 떨어 뜨려야합니까?

삶이나 죽음이 아닌 중복 코드 일뿐입니다. 하나....

많은 일 someBool이 일어나면 이름 이 어떻게 지정 되는지 문제가 될 수 있습니다 . 좋은 이름은==true

if(IsSomeCondition)

또는

if(hasCondition)

또는

if(somethingExists)

예를 들어.

내가 볼 때 someBool == true, 나는 프로그래머가 평가에 대한 아이디어를 내재화하지 않은 것처럼 느낄 수는 없다 . 이것은 근본적인 결함이다.

그러나 나는 아이들에게 대학 교육 프로그램에서 몇 여름을 보냈기 때문에 내 시각이 왜곡되었습니다. 일단 개념을 파악한 후에는 중복성이 분명해졌습니다.

다른 유능한 전문 프로그래머에게는 그렇지 않을 것입니다. 아마도 그들은 초기 프로그래밍에서 개발 한 나쁜 습관 일 것입니다. 그러나 누군가 인터뷰에서 내가 본 첫 번째 일이라면 여전히 겁이 날 것입니다.

그것은 나를 미치게하지만, 나는 그들에게 중복성을 건설적인 방식으로 언급하고 그들이 일치하지 않더라도 그것을 포기한다고 말하고 싶습니다.

또는이 방법을 시도해 볼 수 있습니다 .
사용자 : 부울을 평가하기 위해 다음 코드 규칙을 사용할 수 있습니까?

if (someBool==true)&&(true==true) {}

그들 : 우리는 왜 그렇게할까요? 이 문장의 후반부는 중복되며 항상 참으로 평가됩니다.

당신 : 조지, 당신 말이 맞아요. 바보 나. 그런 다음 모든 중복성이없는 버전을 사용하십시오. 어때요?

if (someBool) {}

동료와의 사소한 문제가 사소한 일이라면 스스로 운이 좋다고 생각합니다.

이 나쁜 습관을 반드시 중단해야합니다. 부드럽게...

코드를 다음과 같이 바꾸는 등호를 쓰는 것은 잊어 버리기 쉽습니다.

if (someBool = true)

예를 들어 C #에서는 오류가 아닌 경고 만 생성합니다. 따라서 경고를 오류로 취급하지 않으면 코드가 실행되고 변수를 true로 설정하고 항상 조건을 입력하십시오.

나는 당신에 동의하지만, 나는 악마의 옹호자를 여기서 할 것입니다 :

언어와 변수 이름에 따라 x == true가 적절합니다.

정수 유형에 대한 정적 입력 및 유형 강제가있는 언어에서 다음 상황을 고려하십시오.

if (actionsAllowed){
    //do actions, since they are allowed
    //...
}

코드의이 섹션을 읽는 사람은 actionsAllowed가 부울 변수라는 것을 즉시 인식하지 못할 수 있습니다. 또한 허용되는 작업 수를 나타내는 정수일 수도 있습니다. 따라서 == true를 추가하면 x가 부울이고, 부울에 강제되는 정수가 아닌 것이 분명해집니다.

if (actionsAllowed == true){
    //do actions, since they are allowed
    //...
}

nullable bools는 어떻습니까?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 

일반적으로, 해당 컨벤션이 프로젝트를 중대한 방식으로 방해하지 않는 한 코딩 컨벤션을 크게 활용하고 싶지는 않습니다. 코드 영역과 주요 밑줄만큼 작은 것들에 대해 많은 논쟁이 제기되는 것을 보았습니다.

즉 == true, 조건문에 추가하는 데 아무런 문제가 없습니다 . 사실, == false부정적인 조건을 테스트 할 때 느낌표가 아니라 사용하는 습관이 있습니다. 더 읽기 쉽다고 생각합니다.

기존의 협약이 있다면 변경할 이유가없는 한 따르십시오. 그러나 실제로 악취가 나는 것은 가치가 없습니다.

Ack. 나는 그 사람입니다. 수치심, 수치심 그것은 내가 배운 방법이고, 내가 머리에서 "자동 서식"하는 방법입니다. 내가 Joel의 선호하는 구문을 사용하는 유일한 것은 bool 변수에 "is"와 같은 동사 접두사가있을 때입니다. 동사가 필요합니다. "is", "can", "did"또는 그렇지 않으면 "="동사를 제공하기 위해 ==가 필요합니다. 나는 그 습관을 잃지 않을 것이므로, 길거리에서 나에게 '안녕하세요'라고 말하지 않으면 이해할 것입니다.

"부울 광기 코드"를 상기시킵니다.

if(someBool == true)
   otherBool = false;
else
   otherBool = true

대신에:

 otherBool = !someBool

개인적으로, 나는 C 기반 언어로 "하지"라고 말하는 방법을 강하게 싫어합니다. 그 작은 느낌표는 간과하기 쉽지 않습니다.

따라서 나는 그것을 완전히 작성합니다 :

if (someCondition == false) {

잠시 읽은 후에도 대칭을 원합니다

if (someCondition == true) {

따라서 !대신을 사용하여 C의 인공물이라고 생각하십시오 not.

언어에 따라 다르지만 일반적으로 나쁜 생각입니다 ...

C에서는 절대로 이렇게 하지 마십시오. 테스트중인 값이 false (0이 아님)가 아니라 "true"로 정의 된 단일 값과 같지 않은 상황을 찾기가 너무 쉽습니다.

Ruby에서는 부울 true를 제외한 모든 항목에서 실패하려는 경우에만이 작업을 수행하십시오.

부울 유형의 C ++ 및 기타 정적 언어에서는 중복 되며 주석 =대신 ==언급 된 대신 잘못 입력 하거나 승격 오류가 발생하면 프로그래밍 오류가 발생할 수 있습니다 .

그게 나쁘다고 생각하니? 어때요?

if(someCondition) {
  return true;
} else {
  return false;
}

나는 선호한다

if (bVal)

또는

if (!bVal)

그러나, 나는 그것을 키우는 것이 사람들을 화나게 할 것을 두려워합니다. 그래서 나의 충고는 그것을 잊어 버리는 것입니다. 죄송합니다!

그가 잘못하고 있다고 말해야합니다.

그...

if (true == someBool) {

}

그가 하나를 잊어 버린다면 그는 글쓰기 스타일에 큰 어려움을 겪고 있습니다.

어때요?

if (x == "true")

왜 STRING입니까?!

실제로 널 입력 가능하면 x == true 테스트가 필요합니다. :)

그런 코드를 작성합니다!

이유는 다음과 같습니다.

"if bla == true"는 문장처럼 읽습니다. "if bla"는 많은 경우에 사용되지 않습니다. 실제 코드를 읽을 때 잘못 들립니다.

또한 컴파일러는 if 블록의 할당에 대해 경고하므로 == true를 사용할 때 실제로 위험은 없습니다. (=와 혼동)

"== true"를 쓰지 않는 사람도 "== false"에 "! ()"를 사용합니까? 정말 못 생겼어 "== false"를 사용하는 경우 진실을 확인하는 두 가지 방법이 아니라 "== true"도 사용하는 것이 매우 일관됩니다.

팀의 일원으로 일하고 있으므로 이러한 일을 함께 해결해야합니다. "다른 사람들과 잘 어울린다"는 초등학교 이후에도 여전히 중요한 성격 특성입니다. :)

일반적으로 '== true'는 생략하지만 팀의 코딩 표준에 포함되어 있지 않으면 잠시 논의 할 가치가 없습니다.

주로 C # 개발자로 동의하지만 이것이 항상 그런 것은 아닙니다. 예를 들어, Javascript에서 ===는 유형 유착을 수행합니다. var x = 3 이라고 가정하면 다음과 같습니다.

if(x) --> true

동안

if (x === true) --> false

JS에서도 if (x == true)를 사용하지 않고 생각해야 할 것이기 때문에 ==와 다릅니다 .

내 사무실에 나타난 다른 점에 대한 이런 종류의 접촉.

bool b = false;

C #에서, 부울 b; 충분하고 b 를 false로 초기화 합니다. 그러나 위의 줄을 작성하는 것이 더 명확하며 최적화 중에 컴파일러가이를 제거해야합니다.

그래서 내 요점은 항상 그렇게 분명하지는 않지만 좋은 습관이 아니며 많은 것이 언어 기능 / 단점뿐만 아니라 선호도에 달려 있다고 생각합니다.

예,하지만 변수가 널 입력 가능하면 어떻게됩니까? (부울?)

일부 언어 (C #)는 'true'와 비교하거나 캐스팅하거나 비교해야합니다.

bool? isAccepted = true;

if((bool)isAccepted)
{...}

if(isAccepted == true)
{...}

젊은이는 규칙을 알고 있지만 노인은 예외를 알고 있습니다.)

최신 C#에서을 다루는 경우 null-able bool다음을 수행해야합니다.

bool? x = null;
bool? y = true;
bool? z = false;
if (x == true || y == true || z == true) {
    // That was the only way that is reasonably readable that I know of
    // to accomplish this expression.
}

tristate가 문제가되지 않는 경우, 보통 무언가를 true/ 와 비교할 이유가 없어야합니다 True. 그러나과 Python같은 다른 언어 에서는 부울이 아닌 식을 C/C++수행 할 수 있습니다 if. 이 언어에는 정수, 포인터, 목록 등을 참 또는 거짓으로 해석하는 고유 한 규칙이 있습니다. 때때로 당신은 그것을 원하지 않습니다. 예를 들어,이 Python 스 니펫에서 :

x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)

여기 z있어야 True하지만, z2있어야합니다 False. 자, Clojure이 - 언어는 또 다른 방법으로이 문제를 접근 and기능은 반드시에 평가하지 않습니다 bool,하지만이 if그것을 처리 할 수 있습니다.

에 관계없이 언어, 언제든지 당신은 자신이 뭔가를 비교 발견 True하거나 False, 아마 주석 가치가있다.

그러한 코딩은 저에게도 잘못된 길을 문지른 것입니다. 예제 식별자의 이름이 "someBool"이지만 부울로 보장되지 않은 변수에서 실수로 해당 코딩 스타일을 사용하면 의도하지 않은 동작이 발생할 수 있습니다. "someBool"값이 "true"또는 "false"가 아닌 경우 결과는 false입니다.

나는 작년에 그러한 구성에 대해 눈이 빛나기 때문에 식별하기 어려운 코딩 스타일로 인해 매우 미묘한 버그가 발생했습니다. "어떻게 틀렸을 까?" "(var)"또는 "(! var)"와 같이 잘 이해 된 표현식의 경우에도 동작을 확인하지 않고 읽거나 코딩합니다.

그래서 코드베이스에 그러한 버그의 존재를 줄이기 위해 몇 가지 코딩 표준을 도입했으며 그러한 미묘한 버그가 나중에 언젠가 우연히 발생할 가능성을 제시했습니다.

1. 모든 표현은 의도에 따라 괄호로 묶어야합니다.
2. 모든 부울 테스트는 "suchBool! = false"와 같이 음수로 표시해야합니다.

새로운 스타일에 맞지 않는 코드를 정리함으로써 그러한 미묘한 버그의 몇 가지 사례를 더 찾아 내 수정했습니다.

다음과 같은 이유로 ActionScript 2에서이 기능을 항상 사용해야했습니다.

var something:Boolean = org.black.box.unknown.ThisMightNotExistYet();

// this is slightly ambiguous
if(something)
{
}

// because if you allow undefined you might actually mean
if(false != something)
{
}

// which can mean something different than
if(true == something)
{
}

// and comparing against what you actually MEAN is less script than
if(undefined != value && value)
{
}

따라서 거의 항상 구체적으로 작성하는 것이 가장 좋습니다.

동의한다. 특히 강력한 유형의 언어로 된 중복 구조입니다.

부울을 잘못 오용하기 위해 Javascript에서 이러한 종류의 구성을 여러 번 발견했습니다 (특히 100 + 라인과 같이 일부 스파게티와 같은 괴물 함수에서).

//create the variable, not initializing it
var flag;
//...
//assing a value to the var, by the example 
flag=$("mycheckbox").selected;
//...

//and at the moment of use it:
if(flag!=true) {
   //code to execute when the checkbox is unchecked
}

이 언어에서 엄격한 유형 정의가 없기 때문에 일부 프로그래머는 false|undefined값을 엉망으로 만들 필요가 없습니다 .

다음과 같은 코드를 가진 동료가 있습니다.

if(something == true)

그런 다음 일종의 테스트 / 디버깅을 위해이 블록을 호출하지 않기를 원하므로 다음과 같이 변경합니다.

if(something == true && false)

그리고 때때로 그는 그것을 다음과 같이 바꿀 것입니다 :

if(false)

최악의 점은, 이런 유형의 디버깅이 때때로 저를 문지르고 다른 개발자가 읽는 것이 실제로 나쁘다는 것입니다!

코드베이스에서 일관성이 중요하다고 말하고 싶습니다. 따라서 조직에서 주로 사용되는 스타일을 사용해야합니다 . 선호하는 스타일을 공식 회사 코딩 지침의 일부로 만드십시오. 이미 지침에 있다면 따르십시오.

(즉, 그것은 또한 실제로 나를 귀찮게 할 것입니다. 그러나 아마도 그것을 크게 만들 수는 없습니다.)

extra == true를 배치하지 않는 것이 좋지만 실수로 실수로 포함시키고 눈치 채지 못하는 경우가 있습니다. 그 사람은 알지 못하고 실수로 배치하지 않았을 수 있습니다. 내 코드를 다시 읽고 때로는 여분의 == true를 배치하여 == true를 제거하는 것을 알 수 있습니다. 나는 때때로 그것을 알아 차리지 못하고 그것을 중복 배치했다는 것을 누군가에게 행복하게 환영 할 것입니다.

어때요?

int j = 1;
for (int i=1; i>=j; i++) ...

그래, 나는 그것을 보았다.