Straight from the horse's mouth
-
In C/C++ there is no boolean datatype and if you used some kind of definitions for boolean values, you had to 'translate' your results in similar ways as shown here. Usually I hid such things in preprocessor macros. Now we do have boolean types and the conditions evaluate to a boolean value, but sometimes people keep working as they are used to.
I'm invincible, I can't be vinced
CDP1802 wrote:
In C/C++ there is no boolean datatype
You evidently can't have programmed in C++ for quite a while, if at all. The "bool" data type has been there since inception, and the relational operators (for built-in types - with operator overloading all bets are off) are defined, by the standard (section 5.9 in the draft I just checked - C++ draft standard[^]), to return bool's. Besides, as may be inferred from the fact this is in the Windows Phone SDK, this is not C/C++ code, but C#.
-
Rob Grainger wrote:
If a programmer doesn't get logic, it's probably time to consider another career choice.
Do you know him? Perhaps he already had more of a career than you think. What if he's just an old C/C++ veteran and never got used to having the conditions result in boolean values (instead of 0 and something non-zero)? Without having looked at the disassembly: Does the compiler not eliminate such simple things? In that case I would usually say that a difference, which makes no difference, is no difference. 'Real' redundancy usually occurs in heaps of spaghetti code where the programmer was unable to separate the tasks at hand and started to copy and paste code blocks where when he became unable to untangle his own mess.
I'm invincible, I can't be vinced
As I stated in my original post "OK, its harmless enough", maybe you didn't read that far. I'd hope the compiler would eliminate this, I'd be surprised if it didn't. However, you can say the same for a myriad of things, such as unused local variables. Should I stop removing such things from my code - after all the compiler will sort out the mess for me, never mind the poor developer's who have to try and understand my code. I'm sure the original writer is doing OK - he's writing code for Microsoft, so presumably is up to the task, but my point was that you'd hope tutorial code would illustrate good coding practices.
-
Rob Grainger wrote:
If a programmer doesn't get logic, it's probably time to consider another career choice.
Do you know him? Perhaps he already had more of a career than you think. What if he's just an old C/C++ veteran and never got used to having the conditions result in boolean values (instead of 0 and something non-zero)? Without having looked at the disassembly: Does the compiler not eliminate such simple things? In that case I would usually say that a difference, which makes no difference, is no difference. 'Real' redundancy usually occurs in heaps of spaghetti code where the programmer was unable to separate the tasks at hand and started to copy and paste code blocks where when he became unable to untangle his own mess.
I'm invincible, I can't be vinced
-
As I stated in my original post "OK, its harmless enough", maybe you didn't read that far. I'd hope the compiler would eliminate this, I'd be surprised if it didn't. However, you can say the same for a myriad of things, such as unused local variables. Should I stop removing such things from my code - after all the compiler will sort out the mess for me, never mind the poor developer's who have to try and understand my code. I'm sure the original writer is doing OK - he's writing code for Microsoft, so presumably is up to the task, but my point was that you'd hope tutorial code would illustrate good coding practices.
You should get resharper to find and remove them from your code for you.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
I begin to understand where redundancy in code comes from. The following example is from the Windows Phone Development material on MSDN:
popToSelectedButton.IsEnabled = (historyListBox.SelectedItems.Count > 0) ? true : false;
OK, its harmless enough, but why on earth do people feel it necessary to explicitly state the result of a logical expression. If a programmer doesn't get logic, it's probably time to consider another career choice.
I have seen such stuff many, many times. They always claim that such approach makes it "easier to read". But the question arises: "For whom?" Don't want to answer, because it will be abusive for some. But writing such sort of a code is the same (yes, it is) as putting the caption "car" on a car (you can make up more examples if you wish). Thanks, I noticed :)
-
In C/C++ there is no boolean datatype and if you used some kind of definitions for boolean values, you had to 'translate' your results in similar ways as shown here. Usually I hid such things in preprocessor macros. Now we do have boolean types and the conditions evaluate to a boolean value, but sometimes people keep working as they are used to.
I'm invincible, I can't be vinced
"if you used some kind of definitions for boolean values, you had to 'translate' your results in similar ways as shown here." Not true! In C[1], the expression is false if it's 0, true otherwise. You NEVER compare to a specific non-false value. You can use a definition for a non-false value, as a "sample" true to return from functions or to set variables, but it is very bad practise to compare anything to that value. This construct may be harmless enough in C#, but a C programmer who used this construct should be larted. Hard. Otherwise he'll start comparing things to whatever value the identifier "true" value, and end up with bugs because in C "true" is just not unique! [1] I don't use C++, but it does have a boolean datatype
-
I begin to understand where redundancy in code comes from. The following example is from the Windows Phone Development material on MSDN:
popToSelectedButton.IsEnabled = (historyListBox.SelectedItems.Count > 0) ? true : false;
OK, its harmless enough, but why on earth do people feel it necessary to explicitly state the result of a logical expression. If a programmer doesn't get logic, it's probably time to consider another career choice.
This particular redundancy is a bit crude, but I've seen others that, while technically just as redundant, struck me as quite forgivable. The dividing line for me is whether the redundancy aids legibility or maintainability. If it contributes to either of those virtues, I'm inclined to shrug.
Of course, "cut-and-paste" redundancies, which replicate code merely to avoid having to think about generality and modularization, are not forgivable, as they degrade maintainability. But that's grammar-school stuff; a programmer who doesn't grasp it should consider hanging it up and going to work in a coal mine.
(This message is programming you in ways you cannot detect. Be afraid.)
-
Rob Grainger wrote:
If a programmer doesn't get logic, it's probably time to consider another career choice.
Do you know him? Perhaps he already had more of a career than you think. What if he's just an old C/C++ veteran and never got used to having the conditions result in boolean values (instead of 0 and something non-zero)? Without having looked at the disassembly: Does the compiler not eliminate such simple things? In that case I would usually say that a difference, which makes no difference, is no difference. 'Real' redundancy usually occurs in heaps of spaghetti code where the programmer was unable to separate the tasks at hand and started to copy and paste code blocks where when he became unable to untangle his own mess.
I'm invincible, I can't be vinced
May I just point out that C++ is a different language? Why would a C++ veteran be given a pass on something like this? If I started doing things in C# because that's the way we had to do them in VB6 or JavaScript, I would get laughed out of this forum. I don't care if the compiler optimizes this away, it's the fact that it's there to begin with that is the problem.
-
I begin to understand where redundancy in code comes from. The following example is from the Windows Phone Development material on MSDN:
popToSelectedButton.IsEnabled = (historyListBox.SelectedItems.Count > 0) ? true : false;
OK, its harmless enough, but why on earth do people feel it necessary to explicitly state the result of a logical expression. If a programmer doesn't get logic, it's probably time to consider another career choice.
-
I begin to understand where redundancy in code comes from. The following example is from the Windows Phone Development material on MSDN:
popToSelectedButton.IsEnabled = (historyListBox.SelectedItems.Count > 0) ? true : false;
OK, its harmless enough, but why on earth do people feel it necessary to explicitly state the result of a logical expression. If a programmer doesn't get logic, it's probably time to consider another career choice.
-
You should get resharper to find and remove them from your code for you.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
CodeRush from DevExpress does that too.
-
As I stated in my original post "OK, its harmless enough", maybe you didn't read that far. I'd hope the compiler would eliminate this, I'd be surprised if it didn't. However, you can say the same for a myriad of things, such as unused local variables. Should I stop removing such things from my code - after all the compiler will sort out the mess for me, never mind the poor developer's who have to try and understand my code. I'm sure the original writer is doing OK - he's writing code for Microsoft, so presumably is up to the task, but my point was that you'd hope tutorial code would illustrate good coding practices.
In this case it's probably not worth getting angry over. Look what the compiler made out of this little test with a false condition:
test = (1 == 0) ? true : false;00000037 xor edx,edx
00000039 mov dword ptr [ebp-40h],edxIt even pulled the old XOR trick out of the hat to set EDX to 0 :) It effectively realized that the condition will always be false and simply copied 0 into the variable. Seriously, coding practices (good or bad, old or new) may become problematic when they are used because somebody said so or because they have always been used. Good practices and rules are not a good substitute for knowing (or being able to verify) what the compiler will make of your code. I had the dubious pleasure of working in a 'best practices' team recently and do not think very much about their religious belief in their rules and that nothing can go wrong as long as they firmly hold onto them. The gray mass in their heads is not just there to keep their ears apart :)
I'm invincible, I can't be vinced
-
I begin to understand where redundancy in code comes from. The following example is from the Windows Phone Development material on MSDN:
popToSelectedButton.IsEnabled = (historyListBox.SelectedItems.Count > 0) ? true : false;
OK, its harmless enough, but why on earth do people feel it necessary to explicitly state the result of a logical expression. If a programmer doesn't get logic, it's probably time to consider another career choice.
That way, ternary operator sucks a bit less. :)
-
I begin to understand where redundancy in code comes from. The following example is from the Windows Phone Development material on MSDN:
popToSelectedButton.IsEnabled = (historyListBox.SelectedItems.Count > 0) ? true : false;
OK, its harmless enough, but why on earth do people feel it necessary to explicitly state the result of a logical expression. If a programmer doesn't get logic, it's probably time to consider another career choice.
-
This could have been written because there is an annoying compiler warning with Visual Studio about coercing an integer to a boolean type. Quite a lot of useless code has been written to silence compiler warnings.
It wouldn't have to coerce an integer to a boolean...
-
I begin to understand where redundancy in code comes from. The following example is from the Windows Phone Development material on MSDN:
popToSelectedButton.IsEnabled = (historyListBox.SelectedItems.Count > 0) ? true : false;
OK, its harmless enough, but why on earth do people feel it necessary to explicitly state the result of a logical expression. If a programmer doesn't get logic, it's probably time to consider another career choice.
At least it wasn't:
popToSelectedButton.IsEnabled = !(historyListBox.SelectedItems.Count > 0) ? false : true;
That kind of thing doesn't not happen all the time!
- Life in the fast lane is only fun if you live in a country with no speed limits. - Of all the things I have lost, it is my mind that I miss the most. - I vaguely remember having a good memory...
-
I begin to understand where redundancy in code comes from. The following example is from the Windows Phone Development material on MSDN:
popToSelectedButton.IsEnabled = (historyListBox.SelectedItems.Count > 0) ? true : false;
OK, its harmless enough, but why on earth do people feel it necessary to explicitly state the result of a logical expression. If a programmer doesn't get logic, it's probably time to consider another career choice.
I do this when converting bool to BOOL or back, for two reasons. 1. Code clarity. 2. Eliminate warnings. And as someone else pointed out, conditional expressions didn't always return a bool type. They used to return integers. So this could just be habit.
-
In this case it's probably not worth getting angry over. Look what the compiler made out of this little test with a false condition:
test = (1 == 0) ? true : false;00000037 xor edx,edx
00000039 mov dword ptr [ebp-40h],edxIt even pulled the old XOR trick out of the hat to set EDX to 0 :) It effectively realized that the condition will always be false and simply copied 0 into the variable. Seriously, coding practices (good or bad, old or new) may become problematic when they are used because somebody said so or because they have always been used. Good practices and rules are not a good substitute for knowing (or being able to verify) what the compiler will make of your code. I had the dubious pleasure of working in a 'best practices' team recently and do not think very much about their religious belief in their rules and that nothing can go wrong as long as they firmly hold onto them. The gray mass in their heads is not just there to keep their ears apart :)
I'm invincible, I can't be vinced
I won't dispute that this is harmless for the generated code, its just redundancy in source code, and in high-level languages (such as C#), that should often be a higher priority.
-
I do this when converting bool to BOOL or back, for two reasons. 1. Code clarity. 2. Eliminate warnings. And as someone else pointed out, conditional expressions didn't always return a bool type. They used to return integers. So this could just be habit.
Not in C#, I hope! (This is from MSDN's WinPhone SDK, so obviously not C/C++)
-
Not in C#, I hope! (This is from MSDN's WinPhone SDK, so obviously not C/C++)
Obvious to folks developing in that arena I'm sure.