title: Does "if ([bool] == true)" require one more step than "if ([bool])"?
body: <p>This is a purely pedantic question, to sate my own curiosity.</p>
  
  <p>I tend to go with the latter option in the question (so: <code>if (boolCheck) { ... }</code>), while a coworker always writes the former (<code>if (boolCheck == true) { ... }</code>). I always kind of teased him about it, and he always explained it as an old habit from when he was first starting programming.</p>
  
  <p>But it just occurred to me today that actually writing out the whole <code>== true</code> part may in fact require an additional step for processing, since any expression with a <code>==</code> operator gets evaluated to a Boolean value. Is this true?</p>
  
  <p>In other words, as I understand it, the option <strong>without</strong> the == true line could be loosely described as follows:</p>
  
  <ol>
  <li>Check X</li>
  </ol>
  
  <p>While the option <strong>with</strong> the == true line would be more like:</p>
  
  <ol>
  <li>Let Y be true if X is true, otherwise false</li>
  <li>Check Y</li>
  </ol>
  
  <p>Am I correct? Or perhaps any normal compiler/interpreter will do away with this difference? Or am I overlooking something, and there's really no difference at all?</p>
  
  <p>Obviously, there will be no difference in terms of actual observed performance. Like I said, I'm just curious.</p>
  
  <p><strong>EDIT:</strong> Thanks to everyone who actually posted compiled results to illustrate whether the steps were different between the two approaches. (It seems, most of the time, they were, albeit only slightly.)</p>
  
  <p>I just want to reiterate that I was <em>not</em> asking about what is the "right" approach. I understand that many people favor one over the other. I also understand that, logically, the two are identical. I was just curious if the actual operations being performed by the CPU are <strong>exactly the same</strong> for both methods; as it turns out, much of the time (obviously it depends on language, compiler, etc.), they are not.</p>