|
True. I didn't expect myself properly, but still. If user enters invalid PIN code, would you use exception to handle this situation? I'd argue you shouldn't.
|
|
|
|
|
The PIN case is different.
When a PIN is entered, it has to be authorised or declined. There is no exception in this.
If the software has used an invalid key for the encryption then THAT could be an exception, in general in is treated as decline.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
PIN is more similar to usual business cases than wings falling off a plane
Anyhow, maybe I could make up a rule that would say:
Do not use exception handling if result of failed operation is displayed to end user, and end user is expected to understand it (there can be exceptions to this )
|
|
|
|
|
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
"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"
It's an OO world.
|
|
|
|
|
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.
|
|
|
|
|
It's not redundant at all...it's explicit. And there's also a difference between "= True" and not leaving it empty. Any non-zero value is "True" but "True" is not any non-zero value.
There's no extra code generated as this is what is actually done when you leave off the "= True" part.
Given there's no difference in the generated code I fail to see your problem. Personally, I prefer explicit coding as you're much less likely to make a mistake.
How's this for redundant?
if (a==1) {
cout << "a=1" << endl;
}
Braces are completely redundant...but you'll never bite yourself by forgetting to put them in when you have to expand the clause in the future.
|
|
|
|
|
In C++, it's explicit. a bool variable can be zero or non-zero, making the check at least desirable.
In VB, or C#, or Java, it's unnecessary most of the time, since a bool can only have two values - and defaults to false instead of null.
|
|
|
|
|
Yes, but how will we know it's True unless we check?
It could be a half truth.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
Well, I use to resolve this kind of problem with a Ctrl+H, replacing '= True Then' by 'Then', simply.
I hate a dirty code....
Ygor Lazaro
|
|
|
|
|
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){
}
but would do it correctly when doing this:
if(boolvalue == true){
}
V.
|
|
|
|
|
Agreed.
Anyway, writing
if(boolvalue == true){
}
is like saying "if boolvalue is true is true"
|
|
|
|
|
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.
|
|
|
|
|
In c# I prefer
if (((boolVar == true) == true) == true) {
I find that three levels is optimum
|
|
|
|
|
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.
|
|
|
|
|
|
I hope this code didn't get in to production because it doesn't work. Try
TruthChecker(false, 1)
I think this will return true
|
|
|
|
|
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!! >>
|
|
|
|
|
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 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.
|
|
|
|
|
Just found this piece of quality in our production code.
try
{
Class1.NullableInt1 = int.Parse(txtSomeUserInput.Text);
}
catch
{
Class1.NullableInt1 = null;
}
...
NB: Class, property and input names changed to protect the inocent.
And people here wonder why our web forms can take 1 minute or more to post back!
|
|
|
|
|
Sadly, the sucker never heard of the Convert class...
|
|
|
|
|
|
Seeing far too much code like that is what made me choose my signature line.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
if (FileType = 0) then
FileSaveAs(Sender)
else begin
case FileType of
1:SaveCDL(FileName,List);
2:SaveDXF(FileName,List);
3:SaveFile(FileName,List);
end;
end;
I came across this in some code (written by someone else) that I am looking through to find the cause of a save/load error.
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill
America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde
Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
|
|
|
|