Redundancy Peaking
-
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
-
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
Don't know about VB, but in C++ a boolean can sometimes have other values then true / false that would go through if you did something like this:
if(boolvalue){
// code here
}but would do it correctly when doing this:
if(boolvalue == true){
// code here
}V.
-
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 confess that I tend to do this, but I do have a reason. I program in multiple languages. Not explicitly calling out an equality in a dynamic and loosely typed language like Ruby can give you unexpected results. A variable will evaluate to true if it is true or has an assigned value (even if it's an empty string). It will evaluate to false if it is false or nil. In the interest of clarity I tend to make logical tests explicit and let the compiler take care of things. Turbo C 1.5 optimized this way back when, so I'm sure VS2010 can handle it. There's no harm in being explicit in one's source code. It's like using "extra" parentheses. It doesn't matter to the tools, but it sure does make reading the code easier for us humans. Not to say i don't appreciate obfuscated C, it's just I do't want to have to modify it and make it work.
-
Unfortunately this is the biggest issue I have about vb. It's too easy to be deep in thought and literally code what you are thinking and make the code more annoying to read. i.e. If control x visible property is true then do this and this and this. I usually pick it up after I have written it and clean it up afterwards but sometimes I've come across code a few months later and go whoops. Hopefully the compiler is smart enough to fix the extra redundancy I've added so it doesn't effect performance.
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
-
Don't know about VB, but in C++ a boolean can sometimes have other values then true / false that would go through if you did something like this:
if(boolvalue){
// code here
}but would do it correctly when doing this:
if(boolvalue == true){
// code here
}V.
Agreed. Anyway, writing
if(boolvalue == true){
// code here
}is like saying "if boolvalue is true is true" :D
-
It may seem structurally sound, but it's a mistake to use exception handling for control flow. First, exceptions are exactly that. Cases which you do not expect should happen in normal workflow, exceptional situations which are caused by a failure in the system. They should not be used to control business logic. However, I am also tempted to use them in this way when I have more than 2 layers of abstraction between business logic decision, and handling of that decision. Second, it's big hit to performance. If this is not client side code, or a single occurrence during request processing, this can be real PITA when you come to a stage you need to optimize performance.
Completely agree with you there! If the wings fall of an airplane in flight then that would certainly raise an exception. However, the function Nagy made is a function that checks if the wings have fallen off. If someone would check something like that they are probably expecting that it could somehow have happened. The person checking it would probably want a true or false :D "Co-pilot to first pilot, the wings have fallen off!" "First pilot here, no sweat, we'll just use another plane for the coming flight" ;P
It's an OO world.
-
I actually sometimes check is some condition is not fulfilled even when there is else branch. This I do in cases when one case of if/else block is expected behavior and in other one i do simple logging/recovery or similar thing. Specifically, I do this when one block is short (less than 5 lines), and put that block in front. In that case, code is more clean to my eye because else block is very near to if block. This is very helpful to me when i have several nested if/else structures. Would that make sense to anyone but me?
Actually that does make sense to me. I just don't usually have a lot of code in If blocks. If there is a lot of code I try to put it in different Methods so the If blocks always fit on my screen completely :) Nested If's are a pain... If there are to many I once again make seperate Methods. If there are three, maybe four (absolute max) I try to keep the If's seperated by some comments that explain why there are so many if's and an empty line. Keeps code quite readable to my eyes :)
It's an OO world.
-
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
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
-
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 feel that it makes reading a program easier when actually seeing the True as well as it's less error prone: MY ARGUMENT TO MY 2 POINTS: 1) VISIBLE Using the statement:
If (myControl.Visible = True) Then
I immediatly know that Visible is a boolean. 2) LESS ERROR PRONE What happens if Visible is actually an unsigned int which can range from 0 to 10 but the programmer forgot to program it correctly? E.g. HE WROTE:
If (myControl.Visible)
INSTEAD OF:
If (myControl.Visible < 10)
This type of bug would be difficult to find if you write your boolean if statements without the True, however easy if not.
"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>
-
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!
