|
hahaha, you got it. Apparently made by Microsoft
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
In near future Google is planning to give space to save your code online.
But your own project related code and documents, you have to maintain in your local server (TFS, VSS etc...), they are providing security.
-- Rushi
|
|
|
|
|
Here's a C code fragment that I recently came across. Not making this up!
if ( len >= 8 )
{
As you may understand, it took me a little while to figure this particular one out
modified on Tuesday, May 10, 2011 4:03 AM
|
|
|
|
|
I think such code should not be commented at all. I know someone who would comment
Such comments are really just littering your code with the obvious. It doubles development time and has no added value... If you need comments to understand that you are obviously not at your right place. A more helpful comment might be WHY the string must be at least 8 chars.
Your example is rather hilarious (or is that sad?) though
It's an OO world.
|
|
|
|
|
My point exactly, thanks. And not only does it double development time, it also puts a burden on the next programmer that has to maintain the code. What should (s)he do? Update the comment? Remove it altogether? In this example, the maintainer apparently forgot to update the comment.
|
|
|
|
|
Fred van Lieshout wrote: What should (s)he do? Update the comment? Remove it altogether?
Shoot the programmer who put the comment there?
It's an OO world.
|
|
|
|
|
Send out a memo saying everyone needs to start using Octal.
|
|
|
|
|
No, no, no. That's too simple.
Instead, send out a memo congratulating everybody on the positive response to the company-wide move to Octal, and gently reminding them that the two hold-outs will be receiving negative reviews this year.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
I say fix the comments and the code when and where needed!
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
If I were to log a bug against it I'd say that "magic numbers were used".
Rather create a constant. Avoid magic numbers at all cost.
#define MAX_STR_LEN 10
public int main()
{
if (CheckStringLength)
{
}
else
{
}
return 0;
}
private boolean CheckStringLength(char* str)
{
boolean result = false;
unsigned int len = 0;
while(str++ != '\0')
{
len++;
}
if (len <= MAX_STR_LEN)
{
result = true;
}
else
{
result = false;
}
return result;
}
In actual fact it would of probebly been better to define the constant in a header file.
This way when the string length changes the actual source file doesn't change but just
the value of the constant defined in the header file and thus the testing of the source
file is not required again.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
modified on Wednesday, May 11, 2011 6:52 AM
|
|
|
|
|
Couldn't agree more. Thanks for the post!
|
|
|
|
|
a) the comment is inaccurate -- the worst kind
b) a comment on this statement is entirely unnecessary
c) as someone else mentioned, the statement it comments uses a magic number. Defining it as a constant might also provide the explanation that this comment fails to provide.
d) than/then confusion: one of my pet peeves.
|
|
|
|
|
I just fell off my chair when I reviewed some old code C# of a colleague
DateTime dt1;
DateTime dt2;
if (dt1.ToString("s").CompareTo(dt2.ToString("s")) < 0)
{
}
Nothing else to mention...
|
|
|
|
|
I have seen some pretty bad ways to compare date, but that is surely one of the worst!
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Found this bit of VB/VBA code to be interesting!
If (Len(Replace(colourStyle, AP_colourStyle, "")) = 0) then
For some reason it took me a little while to realize that it simply meant:
if (Trim$(colourStyle) = Trim$(AP_colourStyle)) then
I could probably leave out the trim$() calls, but I like to make sure there are no pesky extra surronding spaces.
-EM
|
|
|
|
|
Not quite the same. What if colourStyle already has a length of 0.
"You get that on the big jobs."
|
|
|
|
|
|
Best catch of the 2 so far! Here's my 5.
I hadn't noticed that particular morsel, and it is a possibility given the usage of these vars elsewhere in the code, and how the values get attributed to them.
Again fine catch. Kudos!
Hmm, does anyone really say "Kudos" anymore???????
-EM
|
|
|
|
|
Incorrect. Replace() replaces every instance, so with
colourStyle="APAPAP"
AP_colourStyle="AP"
the string would vanish and fire the original if , and not yours.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
|
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
{
}
|
|
|
|