|
Just go ahead and delete all the source code and start from scratch. While you're at it, tell your boss that you're not a mind-reader.
"What annoys me more than anything is someone hearing what my Ph.D. is and then asking me if I believe in Creationism."
Sincerely Yours,
Brian Hart
|
|
|
|
|
I have one right now that I am responsible for. It is the biggest pile of trash ever written. It was done in .net 1.1 by people who had absolutely no clue what they were doing. Every method is about three lines of code to debug just one little piece of functionality you end up with 25 files open by the time you have steeped through it.
And even though this application processes near 500K transactions in each batch every thing is done via datasets with record level processing. It is slower than hell. Even though it it is one web application the project is broken out into 12 projects and there are about 10 config files that need to be changed to move the application. This program is so bad, that I can't even describe how horrible the code is. On a positive note we are supposed to purchasing something to replace it and then I'll only be supporting applications that I wrote.
|
|
|
|
|
I've fell into the same trap; but the original web application was built in ASP and I had to convert it to ASP .NET web app.
plus on top of that the share holder is a jerk.
Dig deep and stick through it, it'll only make you a better developer. I'm at the end of this conversion and I have learned a lot.
Hang in there!
-Noir
|
|
|
|
|
The following code was found in someone's web template. Hope you enjoy the best logic.
if(dt != null)
{
if(dt.Rows.Count != 0)
{
if(dt.Rows[0]["Number"].ToString() == "1")
{
return true;
}
else
{
return false;
}
}
else
{
return false;
}
}
else
{
return false;
}
|
|
|
|
|
Zzzzz...
Half (or nearly) the posts on this forum are like that.
|
|
|
|
|
Oddly enough, I just got rid of some code that looked a bit like that...
bool InitRoutine()
{
bool failed=false;
ValType val;
HRESULT ans = GetValue1(val);
if (ans==S_OK)
{
globalVal1 = val;
}
else
{
failed = failed || true;
}
ans = GetValue2(val);
if (ans==S_OK)
{
globalVal2 = val;
}
else
{
failed = failed || true;
}
ans = GetValue3(val);
if (ans==S_OK)
{
globalVal3 = val;
}
else
{
failed = failed || true;
}
ans = GetValue4(val);
if (ans==S_OK)
{
globalVal4 = val;
}
else
{
failed = failed || true;
}
return !failed;
}
|
|
|
|
|
Ah a follower of the 'there must be only one return statement per method cult'.
I'll be more enthusiastic about encouraging thinking outside the box when there's evidence of any thinking going on inside it. - pTerryBizSquawk
|
|
|
|
|
A misguided one, gives the rest of us a bad name.
Though I don't see where any other return s would go.
|
|
|
|
|
Err ! Was that guy thinking to leave the company while writing this code ?
|
|
|
|
|
Beautiful...
failed = failed || true;
|
|
|
|
|
Short circuit evaluation, man! You don't want to be setting failed to true if it is already!
|
|
|
|
|
What's so bad about that? I'd do it like the following but I've seen far worse than that code:
if (dt == NULL)
return false;
if (dt.Rows.Count == 0)
return false;
return (t.Rows[0]["Number"].ToString() == "1");
|
|
|
|
|
How would you think of this?
return dt != null && dt.Rows.Count > 0 && (int)t.Rows[0]["Number"] == 1;
The last part depends on the data the table contains. But if its clear that the column is filled with integers then this should be more efficient.
|
|
|
|
|
Nah.
This is much more difficult to debug, how would you set a breakpoint anywhere inside such a complex expression?
|
|
|
|
|
Why would you need to? I never have. And for that purpose you can write it specifically for debugging and then put it back to "normal" once you're satisfied with that bit (and not with conditional compiling).
I had to do that sort of thing once a week or so ago. It works for me, others may choose other paths.
|
|
|
|
|
I'm afraid you overlooked the little joke icon; I seldom set a breakpoint so I will not
break up things that belong together just to facilitate a potential later debug action.
|
|
|
|
|
Oh, yes, indeed I did, thanks. It's because the coffee was still dripping. We had a power outage this morning so the coffee maker didn't start automatically. I'd better get a UPS for it.
|
|
|
|
|
If the statement fails, just put a breakpoint on the entire statement. Then, highlight each portion, right click, and select 'Add to Watch'. Viola! You'll see whether or not the statement passed. Rinse and repeat.
|
|
|
|
|
And yes...I know it was a joke. But still...not sure if everyone knows of such
|
|
|
|
|
I certainly didn't, and I probably won't the next time I could use it.
|
|
|
|
|
Thank you for the tip; I rarely use those fancy debug features.
It does widen the scope of the breakpoint, hence requires more human intervention to narrow it down,
but it works.
|
|
|
|
|
|
Right, that's how I do it. Though it may be more a matter of readability/maintainability than of efficiency (in my opinion).
|
|
|
|
|
Just a question:
What if there is no value integer or otherwise in t.Rows[0]["Number"]?
Wouldn't this result into a crash.
Learn from the mistakes of others, you may not live long enough to make them all yourself.
|
|
|
|
|
Thats why I wrote the following after the code block:
The last part depends on the data the table contains. But if its clear that the column is filled with integers then this should be more efficient.
Probably I should have added: ... and otherwise the code will explode.
|
|
|
|