|
Add this comment before anyone notice your code!
if (_Uptime != null)
{
_Uptime.Remove(TraCommon.Tokens.TraService_Speed);
}
{
_Uptime = new Service.Message();
_Uptime.Code = SysCommon.CommandCode.SysUptimeEvt;
}
modified 30-Oct-12 5:56am.
|
|
|
|
|
Sadly, SVN will tell you that it really is ;(
|
|
|
|
|
Embarassing2A: We use SourceSafe.
Embarassing2B: It would still tell you that it really is.
Software Zen: delete this;
|
|
|
|
|
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.
|
|
|
|