|
You could always lie and say the blame was falsely attributed due to corruption.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Embarassing3: I'm the SourceSafe *cough* data base *cough* admin, which means I'm responsible for ensuring the integrity of our source control system.
Besides, this is far from the worst bug I've ever fixed that had been around for a while.
Software Zen: delete this;
|
|
|
|
|
That should make it even easier to "fix". 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
|
At the risk of starting a slashdot-style flame war I refuse to code an if without:
if (condition) {
consequence;
} else {
negative consequence;
}
Can't help it. Can't change it. 56 years old and too old to recover from it. But also pretty hard to miss an 'else'.
Please don't hate me...
|
|
|
|
|
Part of my problem is that, due to changes in style guidelines in my group over time, I have a body of older code that uses K&R braces. My newer stuff, including the aforementioned C#, uses the brace-per-line style.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: It's been there for years.
Then it has been working for years too! Don't fix it!
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Actually, it's not. In the code you don't see, it ends up replacing existing information when it should be adding it. The existing information gets lost.
Software Zen: delete this;
|
|
|
|
|
I did notice that. What I meant is that the application was obviously working for years with that code, unless it's been abandoned.
If it was behaving incorrectly it would've been noticed before. I'm not saying that what the code was doing was correct, just that the application was behaving as expected.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
This is in a portion of the application that logs performance information for our field service organization. The bug caused part of the information to be recorded less often than it was available. The only way it would be noticed is if the folks doing the 'data mining' were paying really close attention, and they're not.
Unfortunately.
Software Zen: delete this;
|
|
|
|
|
This reminds me why i hate ppl who write code like
if (x != y) doThis();
remember one time when somebody added some code -->
if (x != y) doThis(); alsoDoThat();
Took a while in debugger to figure out what was reason :-p Cause not part of my code 
I always write my code after that
if (x != y) {
doThis();
}
Even if have to do only one thing :-p
|
|
|
|
|
That's usually the case for me as well.
Software Zen: delete this;
|
|
|
|
|
Would have been obvious in VB.NET.
|
|
|
|
|
Every line of code in VB.Net is obviously a mistake. 
|
|
|
|
|
Sorry, but I'm more of a 'braces'[^] kind of guy.
Software Zen: delete this;
|
|
|
|
|
It took me a while... and even that I haven't written a line of code in years, I found the mistake. This is the reason why I started coding "if" constructs (and the like) with empty bodies even when they where short.
if()
{
}
else
{
}
Only after that I filled in what had to be filled in.
|
|
|
|
|
That is cool.
What else have you been upto these past years?
|
|
|
|
|
Writing a whole lot of C# that, while it makes FxCop whine like a teenager when the mall closes early, works remarkably well.
Software Zen: delete this;
|
|
|
|
|
of the else clause? will lint catch that error?
David
|
|
|
|
|
etkins wrote: will lint catch that error
I doubt it. There's nothing to differentiate this case from a normal if statement followed by a scope block.
Software Zen: delete this;
|
|
|
|
|
It 's OK to code like this
It was supposed to various _Uptime get the instance in the "{ xxx }"
|
|
|
|
|
I've recently stumbled across a line of code that made me itch to post here. I've reconsidered however and moved on. I didn't fix the line however, since it did the right thing, just in a silly way. In retrospect, there was no good reason not to fix it, but then, and that probably what I was thinking, neither was there a reason to fix it.
Some time has passed, and somehow I was reminded of that line in a different context: code maintenance and code readability. I asked myself, why was it that I could immediately recognize the sillyness of that line? Apparently I was able to instantly understand it! When I think of the more elegant solution, I would have had to look at it for a fraction of a second to grasp it's meaning. Not so the 'silly' code: it was so glaring obvious that just skimming over it shouted it's meaning into my face without any conscious effort on my part.
Here's the equivalent of that line (I don't recall what it was literally):
bool flag = (a > b) ? true : false;
The reason it's instantly obvious is that the resulting value is written out in plain text, rather than hidden in the somewhat obscure use of a condition as value. Some might argue there is nothing obscure in assigning a condition, but in spite of doing that exact thing hundreds of times, I still find myself hesitating a fraction of a second every time I see something like that in another persons code.
Now I wonder: just how silly is code that is so obvious that you immediately know what it does? Should you really change that code to something more elegant? Should you even tell the programmer who did that to do it differently in the future?
If it works, that's good. If it's readable, that's even better. And if the programmer feels comfortable doing it that way, why urge him to do it another way? I feel it's a trade-off between improving style and maintainability, and in the end it's only the latter that counts.
|
|
|
|
|
If it's easy to read and obvious what it does, then I think it is personal style not objectively silly. We write unnecessary characters in our code all the time to make it easier to read (i.e. why is that variable called flag not f?), and that's what the coder has done here. The places where we put 'readability' (itself not an objective quality) over terseness are largely a matter of style.
|
|
|
|
|
No, Silly rocks[^]!
Simple is great, but simple is in the eye of the maintainer.
I consider your example line simply as redundant and might wonder why the long form was chosen.
---
As usual I'm tempted to make it even more explicit:
bool flag = ((a > b) ? true : false) ? true : false;
Now that's better, isn't it? It spells out the purpose right there: if a > b is true, set flag to true, but if a > b is false, set flag to false.
|
|
|
|
|
peterchen wrote: wonder why the long form was chosen
Many possible reasons. Most likely the line is rather old - parts of this codebase are from the 90s. In any case pretty much all the previous programmers came from old style C and weren't used to the type bool just yet. Since internal definitions for a replacement type BOOL tended to vary, the safe way of assigning a value to one was to explicitely assign either TRUE or FALSE, since directly assigning a condition and hoping it would result in the correct integer constant was risky:
typedef short BOOL;
#define FALSE -1 // 0xFFFF in two's complement
#define TRUE 0 // now we have TRUE == !FALSE in two's complement
BOOL b = (x > y); b = (x > y) ? TRUE : FALSE;
(of course, usually the definition was FALSE = 0, exactly because it let you assign conditions directly. But if you weren't sure and looking up the definition would take longer than just typing out the explicit assignment of TRUE or FALSE, why bother?)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
