Classic
-
I'm sure you have all come across something like this. At least I see it way too often. So here it is in C# style:
bool someBoolValue; if (someBoolValue == true) { // do something } else { // do something else }I occasionally find that slipping into my code. Looking back over it a few minutes later reveals my brain fart. :)
------------------------------- Carrier Bags - 21st Century Tumbleweed.
-
I'm sure you have all come across something like this. At least I see it way too often. So here it is in C# style:
bool someBoolValue; if (someBoolValue == true) { // do something } else { // do something else } -
I'm sure you have all come across something like this. At least I see it way too often. So here it is in C# style:
bool someBoolValue; if (someBoolValue == true) { // do something } else { // do something else }that's the classic "the Product guys won't make up their minds, so i'll do it both ways" design pattern.
image processing toolkits | batch image processing | blogging
-
I'm sure you have all come across something like this. At least I see it way too often. So here it is in C# style:
bool someBoolValue; if (someBoolValue == true) { // do something } else { // do something else }While I don't write boolValue == true, I do write boolValue == false since it stands out more then !boolValue.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-
Personally I don't find that to be horrible. It's completely correct and only slightly more redundant. It really makes no difference in practice. And no I'm not trying to defend my usage of it :) I don't lie :) :)
I agree it's not horrible and that it can add to readability but it is still one comparison too many. It might get more obvious in different situation. Like (some stupid example):
bool IsNumberEven(int number) { return ((number % 2 == 0) ? true : false); } int Main() { int someNumber = 2^100; for (int i = 0; i < 100; i++) { while (IsNumberEven(someNumber) == true) { someNumber /= 2; } } }I think it is similar as using String object when one should use StringBuilder. It's OK for small number of iterations or single comparison, but can be time-consuming for large number of iterations. -
I agree it's not horrible and that it can add to readability but it is still one comparison too many. It might get more obvious in different situation. Like (some stupid example):
bool IsNumberEven(int number) { return ((number % 2 == 0) ? true : false); } int Main() { int someNumber = 2^100; for (int i = 0; i < 100; i++) { while (IsNumberEven(someNumber) == true) { someNumber /= 2; } } }I think it is similar as using String object when one should use StringBuilder. It's OK for small number of iterations or single comparison, but can be time-consuming for large number of iterations. -
I've always assumed that if(aBool) is simply a short-hand for if(aBool == true), and they should be completely equivalent to the compiler. If they are not for some reason, it would be a trivially easy optimization for the compiler to make.
-
I've always assumed that if(aBool) is simply a short-hand for if(aBool == true), and they should be completely equivalent to the compiler. If they are not for some reason, it would be a trivially easy optimization for the compiler to make.
-
I'm sure you have all come across something like this. At least I see it way too often. So here it is in C# style:
bool someBoolValue; if (someBoolValue == true) { // do something } else { // do something else }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.
-
I'm sure you have all come across something like this. At least I see it way too often. So here it is in C# style:
bool someBoolValue; if (someBoolValue == true) { // do something } else { // do something else }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
-
Personally I don't find that to be horrible. It's completely correct and only slightly more redundant. It really makes no difference in practice. And no I'm not trying to defend my usage of it :) I don't lie :) :)
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 preferif (someridiculouslylongexpression==false)overif (!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 -
Personally I don't find that to be horrible. It's completely correct and only slightly more redundant. It really makes no difference in practice. And no I'm not trying to defend my usage of it :) I don't lie :) :)
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
-
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
Not with C# compiler right? The compiler 'barks' and strongly recommends an explicit casting. Isn't it?
Vasudevan Deepak Kumar Personal Homepage Tech Gossips
-
Not with C# compiler right? The compiler 'barks' and strongly recommends an explicit casting. Isn't it?
Vasudevan Deepak Kumar Personal Homepage Tech Gossips
Yep, in C# you can't compare a
boolto1or aninttotruewithout explicit casting.Luis Alonso Ramos Intelectix Chihuahua, Mexico
-
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 :)
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 -
Personally I don't find that to be horrible. It's completely correct and only slightly more redundant. It really makes no difference in practice. And no I'm not trying to defend my usage of it :) I don't lie :) :)
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
-
I agree it's not horrible and that it can add to readability but it is still one comparison too many. It might get more obvious in different situation. Like (some stupid example):
bool IsNumberEven(int number) { return ((number % 2 == 0) ? true : false); } int Main() { int someNumber = 2^100; for (int i = 0; i < 100; i++) { while (IsNumberEven(someNumber) == true) { someNumber /= 2; } } }I think it is similar as using String object when one should use StringBuilder. It's OK for small number of iterations or single comparison, but can be time-consuming for large number of iterations. -
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; } }:)