|
That's a great point and here's my 5.
These vars could never have that type of situation due to how they get their data, but the basic premise you point out is correct.
Assuming that the 2 vars refer to the same type of data (i.e. a "ColourStyle"), but from 2 different sources, I still don't see why someone would create that line of code. What design instructions would lead someone to use that type of logic? Any ideas, I'm interested to see other's take on this.
-EM
|
|
|
|
|
emartinho wrote: These vars could never have that type of situation due to how they get their
data
But in cases where your development and coding is outsourced (and maybe even internal), this is a bad premise in itself, since they will cut and paste so MUCH of your existing code base, the error these two variables 'will never encounter' will show up everywhere else in your code.
|
|
|
|
|
Both code goes to the category of Hall of Shame?
|
|
|
|
|
For our remote embedded system, we have a convoluted patching mechanism. For our latest release, to solve another problem with large archives I rewrote our unzipper. It worked great except a critical file would get deleted. We threw more logging, changed the organzation of the zip files to no avail. Another developer added some logging which identified when the file in question was getting deleted and asked me what circumstances led to that error condition. I looked over his shoulder, my eyes went up a few lines and I saw it.
To take care of a very rare edge case, I added a check. Problem is that if the file being unzipped was exactly the same size as the unzip buffer, that check would erroneously fail. To make it worse, I realized that the check would have never failed (aside from the above) unless the zip file was deliberately corrupted, including adding fake CRCs and even then it would be very difficult. Point being, I added a test for an edge case that would never happen causing an edge case that did!
|
|
|
|
|
Found this in JavaScript code from one of our designers
if(a>b && a<=b)
{
}
else
{
}
|
|
|
|
|
Well I am sure a designer would read that as...
if a is looking at b while on the other side of the bushes b is entering a from behind
do something
else
do something else
ALTERNATIVELY
The designer knows not how to apply multi lines commenting?
I may or may not be responsible for my own actions
|
|
|
|
|
Yes, that is truly an impeccable bit of logic.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
No this is just a more esoteric way of commenting out code.
//do something is the stuff being commented out and
//do something else is now being done instead.
I think this is obvious, isn't it?
Cheers!
|
|
|
|
|
I dont believe your designer wanted it that way, but a comparison to a NAN is always false.
I am using a similar NAN-Check
if (x != x) ...
gets true if x is NAN
|
|
|
|
|
if(x.isNaN()) (Java)
if(double.IsNaN(x)) (C#)
modified on Wednesday, May 4, 2011 1:53 PM
|
|
|
|
|
|
the unequality test is more portable
i actually used it in CUDA, afterwards i found out there exists an isnan(x) builtin function
now porting to other languages is more easy
|
|
|
|
|
Then surely one will want to do:
if(a > b && a <= b && a != b && !isNaN(a + b)) { }
|
|
|
|
|
I think I just threw up a little in my mouth.
|
|
|
|
|
laugh all you wish, but that's not to far fetched from something some of the tiddlywinks I had classes with would do. Might be why I have a job and they don't but, that's another issue...
Programming is a race between programmers trying to build bigger and better idiot proof programs, and the universe trying to build bigger and better idiots, so far... the universe is winning.
|
|
|
|
|
//do something else; like working as an accountant maybe!
"You get that on the big jobs."
|
|
|
|
|
LOL, that's fantastic.
Designers are like women, you can't understand!
|
|
|
|
|
This a standard design pattern (SDP) used by Governments, NATO, UN etc in deciding when to take action when civilians are being killed or persecuted
"No matter what - don't doing anything"
Clearly the designer is very well read and is destined for great things.
Note:
The design pattern is also used in banking to calculate if the bonus should be
a. Very large
or
b. Just embarrassingly large.
Athough it has to be admitted the design pattern is somewhat flawed as no banker has ever been embarrassed!
|
|
|
|
|
Should we assume that it wasn't done intentionally as a temporary bypass?
|
|
|
|
|
Doesn't apply to Javascript, but in languages that allow separately overloaded operators, this could have a (nefarious) significance.
|
|
|
|
|
and thats why they can't (designers(can't code)).
Excuse the pun.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
modified on Tuesday, May 10, 2011 4:14 AM
|
|
|
|
|
I was to assist repair a computer.
I went comfotable assuming it was a small issue.
I found on the users machine destop full of files my attitude began changing.
I asked the problem and told that the computer has to be restarted to work,
I checked, on moving the mouse the computer hangs and nothing could be done
then i restarted it, i realised that the computer was fully loaded with virus.
I tried installing antivirus, no .exe could open then i vomitted
I only read newbie introductory dummy books.
|
|
|
|
|
Sorry for asking... but what's your point...
(yes|no|maybe)*
|
|
|
|
|
Remove your 5 fingers from your throat. The vomitting should cease.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
That's highly interesting.
I won’t not use no double negatives.
|
|
|
|