Redundancy Peaking
-
In c# I prefer
// to be sure, to be sure, to be sure
if (((boolVar == true) == true) == true) {I find that three levels is optimum
-
And I ran this test once with "if mybool" and once with "if mybool = True". No difference in speed. 1st one showed 33 seconds, 2nd one showed 32 seconds.
Module Module1
Sub Main() Dim mytime As Date Dim mybool As Boolean Dim mydiff As TimeSpan Dim j As Double mytime = TimeOfDay() While mytime = TimeOfDay() End While mybool = True j = 0 For i = 1 To 100000 For j = 1 To 100000 If mybool = True Then j = j + 1 End If Next Next mydiff = TimeOfDay() - mytime Console.WriteLine(mydiff) Console.ReadKey() End SubEnd Module
Had you taken a look at the disassembly, you would have discovered that the compiler generates exactly the same code in both cases. There is no real need for a test program.
"Dark the dark side is. Very dark..." - Yoda ---
"Shut up, Yoda, and just make yourself another toast." - Obi Wan Kenobi -
Using the same technique thrice may not guarantee correct results. So you may want to try:
if (((boolVar.ToString().ToLower().Equals("true") == true) == (true == true)) {
}:)
"Don't confuse experts with facts" - Eric_V
That won't work on a German system: boolVar.ToString evaluates to "Wahr" or "Falsch". Some time ago I posted a coding horror where just that happened by implicit conversion from bool to string.
-
Had you taken a look at the disassembly, you would have discovered that the compiler generates exactly the same code in both cases. There is no real need for a test program.
"Dark the dark side is. Very dark..." - Yoda ---
"Shut up, Yoda, and just make yourself another toast." - Obi Wan KenobiUmmm...if you dissassemble something isn't there a program to disassemble? Ergo a test program? I was simply providing an example that proves that this is not redundant code at all. The disassembly does confirm it though so thanks for that observation.
-
Ummm...if you dissassemble something isn't there a program to disassemble? Ergo a test program? I was simply providing an example that proves that this is not redundant code at all. The disassembly does confirm it though so thanks for that observation.
What I meant is, that when such a question arises, I simply write both lines in the application I'm working on and then look what I find in the disassembly. Why try to measure something that you can examine directly? As to the topic: I see that just as you do. It's not redundant and has no impact (in all languages I commonly use). A difference which makes no difference is no difference.
"Dark the dark side is. Very dark..." - Yoda ---
"Shut up, Yoda, and just make yourself another toast." - Obi Wan Kenobi -
In c# I prefer
// to be sure, to be sure, to be sure
if (((boolVar == true) == true) == true) {I find that three levels is optimum
I prefer to define my own truth... cause ya never know. And make a recursive check because it might change at some point. Set a nice constant for how many times you should check it. And don't forget to constant your zero because it might change someday as well.
const bool TRUE = true;
const int ZERO = 0;
bool TruthChecker(bool checkValue, int checkCount)
{
if(checkCount == ZERO)
return (checkValue == TRUE);
else
return (checkValue == TruthChecker(checkValue, --checkCount));
}With this defined we can now test ensure our boolean holds up!
const int CHECK_TRUTH_COUNT = 42;
...
if(TruthChecker(boolVar, CHECK_TRUTH_COUNT))
{
//Do some kewl stuff
}Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
Why? Why? Why check an already boolean result? Noticed this redundancy in many parts of an ill written app.
If myControl.Visible = True Then 'Some Code Else 'Some other code End IfI don't know why, it's just plain turn off to see this redundancy!
- Just that something can be done, doesn't mean it should be done. Respect developers and their efforts! Jk
I've seen similar stuff many, many, many times. I believe the author is paid not only for lines of code but for columns as well.
-
I prefer to define my own truth... cause ya never know. And make a recursive check because it might change at some point. Set a nice constant for how many times you should check it. And don't forget to constant your zero because it might change someday as well.
const bool TRUE = true;
const int ZERO = 0;
bool TruthChecker(bool checkValue, int checkCount)
{
if(checkCount == ZERO)
return (checkValue == TRUE);
else
return (checkValue == TruthChecker(checkValue, --checkCount));
}With this defined we can now test ensure our boolean holds up!
const int CHECK_TRUTH_COUNT = 42;
...
if(TruthChecker(boolVar, CHECK_TRUTH_COUNT))
{
//Do some kewl stuff
}Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
I hope this code didn't get in to production :laugh: because it doesn't work. Try
TruthChecker(false, 1)
I think this will return true :(
-
Why? Why? Why check an already boolean result? Noticed this redundancy in many parts of an ill written app.
If myControl.Visible = True Then 'Some Code Else 'Some other code End IfI don't know why, it's just plain turn off to see this redundancy!
- Just that something can be done, doesn't mean it should be done. Respect developers and their efforts! Jk
I hate to say it, but I do that boolean crap in if...thens. It's the only way some people can understand the code when they read it.
-
And I ran this test once with "if mybool" and once with "if mybool = True". No difference in speed. 1st one showed 33 seconds, 2nd one showed 32 seconds.
Module Module1
Sub Main() Dim mytime As Date Dim mybool As Boolean Dim mydiff As TimeSpan Dim j As Double mytime = TimeOfDay() While mytime = TimeOfDay() End While mybool = True j = 0 For i = 1 To 100000 For j = 1 To 100000 If mybool = True Then j = j + 1 End If Next Next mydiff = TimeOfDay() - mytime Console.WriteLine(mydiff) Console.ReadKey() End SubEnd Module
mdblack98 wrote:
Dim j As Double
...
j = 0
For j = 1 To 100000
...
j = j + 1
...
NextOuch! * Declaring a control variable as a Double * Redundant initialisation of a variable immediately before using it as a control variable * Doing integer arithmetic on a Double (in the For and in the assignment statements) * Changing the control variable inside the loop * Writing a Hall Of Shame contender in response to a Hall Of Shame entry. Priceless!