Classic

[Lost User]

I don't know if that is true. Maybe someone with deeper knowledge than me could answer that. If it is true though, I should 'recompile' my coding practices ;)

[Lost User]

I ran some tests for speed for both cases and the results show that your assumption is correct. It seems compiler is smarter than I thought ;) So this case is closed and I learned something new to me and that is always a good thing :)

[Pete OHanlon]

I'm going to be pedantic here and state that the do something condition will never be executed in this example. BTW - to answer your question, the compiler recognises that if (a == true) is functionally equivalent to if (a) because it is clever enough to know that all parts of the if condition must be boolean conditions.

Deja View - the feeling that you've seen this post before.

[Luis Alonso Ramos]

In some languages TRUE is actually an int, mostly 1. But BASIC languages (VB for one), define TRUE as NOT FALSE (where not is the 2's complement), so TRUE is actually -1. If you are interacting with different languages, you have to take this into account -- for example, a Windows API return value in Visual Basic.

Luis Alonso Ramos Intelectix Chihuahua, Mexico

My Blog!

[peterchen]

It's ok e.g. in C#, but in C/C++ this habit can lead to nasty bugs. If you work with multiple libraries, you probably have to deal with bool, BOOL and VARIANT_BOOL. While bool is fine (unless abused in the assignment), BOOL is usually used as "any nonnegative value is true", and the respective TRUE constant is defined sometimes as 1, sometimes a (!FALSE) which would expand to -1. VARIANT_BOOL explicitely defines -1 as VARIANT_TRUE. I know that some people prefer if (someridiculouslylongexpression==false) over if (!someridiculouslylongexpression) since the not can get lost quickly for the quick reader. However, I discourage this habit, as it may fail with the "fak" boolean types.

---

We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist

[Vasudevan Deepak Kumar]

dighn wrote:

slightly more redundant

:confused: It is a way bit explicit right? Do you mean to say it affects any of the coding guidelines? C# actually advocates and prefers explicit typecasting too. And similarly an explicit mention should be a welcome though a bit strange. What do you way? :)

Vasudevan Deepak Kumar Personal Homepage Tech Gossips

[Vasudevan Deepak Kumar]

Not with C# compiler right? The compiler 'barks' and strongly recommends an explicit casting. Isn't it?

Vasudevan Deepak Kumar Personal Homepage Tech Gossips

[Luis Alonso Ramos]

Yep, in C# you can't compare a bool to 1 or an int to true without explicit casting.

Luis Alonso Ramos Intelectix Chihuahua, Mexico

My Blog!

[wk633]

You ran a test for speed??? I put it in an app:

    bool IsNumberEven(int number)
    {
        return ((number % 2 == 0) ? true : false);
    }
    private void Form1\_Load(object sender, EventArgs e)
    {

        if (IsNumberEven(2))
        {
        }

        if (IsNumberEven(2) == true) { }
    }

checked with ildasm, and they both turn into exactly the same IL code.

// Code size 34 (0x22)
.maxstack 2
.locals init ([0] bool CS$4$0000)
IL_0000: nop
IL_0001: ldarg.0
IL_0002: ldc.i4.2
IL_0003: call instance bool csharpWindowsApp.Form1::IsNumberEven(int32)
IL_0008: ldc.i4.0
IL_0009: ceq
IL_000b: stloc.0
IL_000c: ldloc.0
IL_000d: brtrue.s IL_0011
IL_000f: nop
IL_0010: nop
IL_0011: ldarg.0
IL_0012: ldc.i4.2
IL_0013: call instance bool csharpWindowsApp.Form1::IsNumberEven(int32)
IL_0018: ldc.i4.0
IL_0019: ceq
IL_001b: stloc.0
IL_001c: ldloc.0
IL_001d: brtrue.s IL_0021
IL_001f: nop
IL_0020: nop
IL_0021: ret

[John R Shaw]

Actually I do not know why that was even posted, there was absolutely nothing wrong with that code. Now if there was something in the “do something…” sections, that showed a problem – then it might have made since as a problem – otherwise it is great and legitimate code. Tinko101 – can just ignore my comment, because I have only been writing code for about 19 years or so, but I agree with you. ;)

INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra

[OR0N]

Testing if the number is even with modulus is the real horror .. :P

[Lost User]

Actually the real horror would be: bool IsEven(int someNumber) {  if (someNumber == 2 || someNumber == 4 || someNumber == 6 || // ok, you get the point)  {   return true;  }  else  {   return false;  } } :)

[OR0N]

A rumour has it that it always can be worse :)

[TClarke]

The only thing I can see wrong is that the boolean value isn't initialized. Now that is ban practice as in C/C++ values only get a default value in Debug mode. In Release mode it could be anything

[Tom Clement]

I assumed the posted code was just missing an elipsis. Presumably there was something to set the Boolean value.

Tom Clement Serena Software, Inc. www.serena.com articles[^]

[TClarke]

Tell the compiler that ;)

[kenpanda]

mmm...not sure !:mad: I already see worse ! You write a first test if (boolValue == true) during debugging, it appaers that you have to change the test if (boolValue != true) after a second debug you wish to change it again if (boolValue != false) As summary, do you think that this code is really readable, even the performance is the same... : **if (boolValue != !false)**:laugh:

[dean wilde]

I dont think theres anything wrong with that, the compiler is going to optimize it anyways, the reason I like it is because is simpler to read than the alternative and simpler is always better in code. The only argument you could make that one shouldnt do that is if you mistype and put if(someBoolValue=true) and do an assignment instead of a comparision. The workaround to that is to either put constants on the left hand side if(true==someBoolValue), which you should already be doing so the compiler catches other similar mistakes (like null checks), or set the compiler warning level to 4, which I would also recommend you do to let the compiler detect other bugs.

[dojohansen]

That, and the classic ternary (sMethod == "read"? true : false) What I never understood is why these people stop so soon. The concept is readily extended... if (doIt) => if (doIt == true) => if ((doIt == true) == true) ... and combined bool flag = ((doIt == true) == true? true : false); if (flag != false) doIt = true; We could go on all night...

[dojohansen]

It makes no difference, just like if (((true == myFlagVariable) == true) != false) is in fact equivalent to if (myFlagVariable) It's just that one version shows that the programmer understands that a boolean variable is in fact a boolean expression. So while it doesn't do much damage, it does show a lack of understanding -- excepting the occasional brainfart, which can surely happen to anyone. I've also noted the habit of C programmers to write if (null == var) ... which to me just doesn't read naturally! I realise that they do this to avoid an unintensional assignment - a common and often subtle bug in C code: if (var = null) ... But in C# an assignment statement is not legal in an if condition, so it is a pointless practice. But I won't deny that habits are powerful and it may not be so easy for an old dog (C programmer) to change his ways. (I wish it was "her" ways more often, but for some reason girls are few and far between in our community.)