Comment On Avoiding the Exception

Moving on

almost first

try {
"frist"
} catch(NotFristException) exception {
Response.Redirect("second.aspx");
}

A little talkative, isn't he?
Fixed:

catch (Exception ex)

{

    CommonLoggerHelper.DumpException(ex);

    Response.Redirect("default.aspx");    //Lazy, loses all user's quiz answers

}

It is perhaps in our best interests to have interesting things to say in the comments. It is said that nine tenths of TDWTF time should be spent reading the WTF, but I find myself spending nine tenths of the time writing comments. So all I have to say for this is a big LOL. I feel a little dirty, but time grows short and I must move on.

I imagine he asked himself, "Should I take the time to write the code to remember the users answers, or should I just write a long rambling explanation on why I won't?"

:10bux: says there is already information stored per user and he was too stupid to use it.

i feel dirty and lazy too

I like the fact that his diatribe is massive, talking about exceptional circumstances such as server resets and what not, all the while handling these exceptional circumstances by, well, not handling them appropriately.

captcha: secundum - latin for the "wtf?" part of reading bad code.

To me the key element is "Since this is simply a tutorial application". If it is NOT intended to ever be used in a production environment (i.e. as a "real" application), this approach is warranted.

Look at the code samples that sip with products, that appear in magazines, appear in blogs, etc. It is extremely rare that the code is "production quality".

At least the author has indicated in the comments what some of the issues with the "tutorial" implementation are.

Now if this became a production code base, then WTF!

"Since this is simply a tutorial application"...

...the WTF probably lies with someone other than the author of the comments.

Simple explanation: he is being paid per line of code written. Somehow, in his company, that includes comments.

I think what he really meant to say is:

/*

 * I get paid using the LOC method of productivity,

 * so I need to come up with more "L"s.

 */

TRWTF is using Response.Redirect("default.aspx") rather than Response.Redirect("./"). default.aspx should never be linked to or redirected to explicitly, just implicitly. (Posting to default.aspx is another matter due to IIS's insane "no posting to a default document" rule.)

See:

http://www.experts-exchange.com/Programming/Languages/.NET/ASP.NET/Q_23108345.html

tl;dr

TheCPUWizard:

To me the key element is "Since this is simply a tutorial application". If it is NOT intended to ever be used in a production environment (i.e. as a "real" application), this approach is warranted.

Look at the code samples that sip with products, that appear in magazines, appear in blogs, etc. It is extremely rare that the code is "production quality".

At least the author has indicated in the comments what some of the issues with the "tutorial" implementation are.

Now if this became a production code base, then WTF!

I didn't take it as the application itself was a tutorial on programming, rather that it is something like a CBT app.

Adequate explanatory comments play a fundamental role in fostering a codebase that is easy to update and maintain. But seriously, we don't need your life story. If your comment has a word-count comparable to the average novella then you've provided too much detail.

I especially like the way this coder references his other comments, almost as though he wants us to go trawling through other code files so we can piece together his complete odyssee. I think he'd be better off writing fiction than code.

Anonymous:

Adequate explanatory comments play a fundamental role in fostering a codebase that is easy to update and maintain. But seriously, we don't need your life story. If your comment has a word-count comparable to the average novella then you've provided too much detail.

I especially like the way this coder references his other comments, almost as though he wants us to go trawling through other code files so we can piece together his complete odyssee. I think he'd be better off writing fiction than code.

Even better would be a Choose-Your-Own-Odyssey following many possible routes through all of the comments in the codebase

Oh, I've seen this type of coder before. This type of coder is not the best at writing actual code but is great at making excuses as to why it's OK to not write the code. Long rambling comments that basically amount to "I should be doing some real work here but it's awfully tricky so here is an unnecessarily verbose explanation as to why it's OK to skip it so I can get on with something simple like making icons". This type of coder is easily identified by the ratio of functional lines to commented lines, as well as the vacant look on his face. His most commonly used design pattern is:

// TODO

Oh yeah, done the easy way out.

OLAP::~OLAP()

{

    ::CloseHandle(connection);



    // Let the OS deal with the memory deallocations

    // Lazy,  I know...

}

Jim:

Anonymous:

Adequate explanatory comments play a fundamental role in fostering a codebase that is easy to update and maintain. But seriously, we don't need your life story. If your comment has a word-count comparable to the average novella then you've provided too much detail.

I especially like the way this coder references his other comments, almost as though he wants us to go trawling through other code files so we can piece together his complete odyssee. I think he'd be better off writing fiction than code.

Even better would be a Choose-Your-Own-Odyssey following many possible routes through all of the comments in the codebase

"If you want to know why the developer hasn't implemented a proper logging framework, turn to page LogUtils.cs."

"If you want to know why the developer hasn't implemented exception handling, turn to page ErrorHandler.cs."

"If you want to get some work done, fire the developer then turn to page Form1.cs."

I'd solve it differently. First, I'd write this:

//todo: make sure that we don't lose any of the answers if this is triggered.

And then hope another programmer has the will and the free time to add a bonus database layer that is only read from when the main db crashes along with its failover, and sets something up so that the data is persistent across sessions.

So, in essence, If someone has an Starfleet Engineering mentality, who thinks they can't live without a secondary backup, it'll get fixed. If not, I can say I warned them all, and they didn't listen.

So... It sounds like somebody cut and pasted some tutorial code directly into a production environment. Awesome.

Try Catch is for sissies!

Okay, I heard of projects with a lack of documentation, but this? Seriously? I'd like to hire that guy right now. He'd never have to write one piece of code. Brilliant. Just brilliant. A peer to Shakespeare.

One of my former colleagues took this technique to the logical conclusion: he wrote only comments, and no code at all. It transpired this was because he didn't know anything about the language he was ostensibly coding in. The ghastly truth was revealed on the day of the code review; he didn't turn up, and was never seen again.

They were beautiful comments, though.

Whiskey, Eh?:

Simple explanation: he is being paid per line of code written. Somehow, in his company, that includes comments.

Any good metrics program tracks the number of comment lines. This guy was short for the week and added a weeks worth to the exception block that had to be put in when his code tried to dereference a null object. Now his per cent comment lines will be right on target.

If the rest of the application is coded reasonably defensively, I'm not sure what he's going on about. The biggest mistake I can see is not generating a error message so the user knows why he just lost his answers. If a database connection is lost, or some other database problem happens, that's an exceptional situation. Log it, display it, and move on. Let the testers and the customers report real world failures.

That was my reaction, too. The real WTF is that someone seems to have taken a tutorial and put it into production without finishing the "exercises for the reader" part of the tutorial.

Resuna:

That was my reaction, too. The real WTF is that someone seems to have taken a tutorial and put it into production without finishing the "exercises for the reader" part of the tutorial.

Agreed. Although I kind of hope that he/she typed it all out from an actual dead-tree book. :)

or other database malladies occur

Bad girl, down!

TRWTF is he didn't return Boolean.FileNotFound;

cookies....

The comment is a bit long but sometimes I see developers solving hard problems of little worth in the same time they could have solved dozens of small but important problems.

An example would be one I saw who solved a series of rather hard spacing problems between FF and IE when they needed to solve the problem of IE people not being able to log in.

goggling around I see a few versions of this floating about -- i notice that the example on experts-exchange is VB.net but the example here is C#- which implies that someone actually went and changed their ' to // or vice versa?

immitto - "imma immitto somethin righnow"

TheCPUWizard:

To me the key element is "Since this is simply a tutorial application". If it is NOT intended to ever be used in a production environment (i.e. as a "real" application), this approach is warranted.

Uhhhh, not if the user has to pay to get the quiz or he has something to lose, like a grade or something, or the quiz is long and it is imperative to get users' input.

If this is an application that 1) users have to pay for (or spend a considerable time getting through it) or 2) the owner has an incentive to get it out to users, and 3) you get paid to write it and maintain it, it is production, it is real

Sorry man, but bad software engineering is bad software engineering.

I mean, how hard it is to save state between pages or questions? People do it all the time successfully. There are so many approaches it's not even funny. It's not rocket science on a tight schedule.

Don't know the context of this application, but with all things being equal, that wall of comment is just an attempt of CYOA rather than a pragmatic hack under duress.

TheCPUWizard:

Look at the code samples that sip with products, that appear in magazines, appear in blogs, etc.

In 15 years, I've only seen that, like probably four or five times. It is not that common.

TheCPUWizard:

It is extremely rare that the code is "production quality".

Uh, depends on where you work and who you work with. I'll grant that no software if bug free, but from there to say few pieces of code is "production quality" is a bit of a stretch.

TheCPUWizard:

At least the author has indicated in the comments what some of the issues with the "tutorial" implementation are.

He really didn't explain anything. He simply created a wall of text to poorly justify his wtf.

TheCPUWizard:

Now if this became a production code base, then WTF!

Apparently it is. Just because it's not a financial transaction system, that does not make it a toy or non-production.

The real WTF is that he will never revisit the code and fix it unless there are complaints that it's broken. And then I'll be the guy working there who has to deal with it.

"Redirect" in all its incarnations is TRWTF.

A URL is supposed to be a Uniform Resource Locator (see http://en.wikipedia.org/wiki/URL )

So when your site visitor requests a resource, you give it to them, or, if that is not possible, explain why in response to the original request.

All a "redirect" accomplishes is telling the browser "ooh your naughty user asked for foo when he should have asked for blargh, try again!" at which point the browser (probably) obediently returns asking for blargh, which you already knew was going to be the answer, but you refused to give it on the first request, so here we go all over again.

This cargo-cult copycat obsession with redirecting people all over the place has led to the web we know and love today, where most of your bookmarks to things you really care about are broken. For example, I want to see how my tdwtf stock is doing. I should be able to choose my bookmarked link to my brokerage's "today's gain/loss" page. But oh noes I'm not logged in. So instead of giving me a login form then and there which, when submitted back to the same URL, would result in what I originally asked for, I get redirected to "the one and only true login page". By the time I finish logging in the site has usually forgotten my original request so I end up at some stupid marketing page. Or maybe that's on purpose...

At least it's well commented.

Ken B.:

I think what he really meant to say is:

/*

 * I get paid using the LOC method of productivity,

 * so I need to come up with more "L"s.

 */

I thought the "C" in "LOC" stood for code not comments!

Maurits:

TRWTF is using Response.Redirect("default.aspx") rather than Response.Redirect("./"). default.aspx should never be linked to or redirected to explicitly, just implicitly. (Posting to default.aspx is another matter due to IIS's insane "no posting to a default document" rule.)

IIS's insane

Simplified that for you...

But yes, you're right. If you design so that all your URLs end in / you won't have to break the entire freaking web when you decide to upgrade from .aspx to .whatever

When a site is reorganized it makes no sense to tell a *user* clicking on a link that the page isn't there anymore. You tell the search engines (301) and send the user to the best available location as transparently as possible.

And yes, that is a reasonable interpretation of "URLs are forever".

TheCPUWizard:

To me the key element is "Since this is simply a tutorial application". If it is NOT intended to ever be used in a production environment (i.e. as a "real" application), this approach is warranted.

Look at the code samples that sip with products, that appear in magazines, appear in blogs, etc. It is extremely rare that the code is "production quality".

At least the author has indicated in the comments what some of the issues with the "tutorial" implementation are.

Now if this became a production code base, then WTF!

Tutorial code should show good practices. That makes this even worse. If you're [sic] code doesn't even work, then why should I learn from you?

Something tells me that resetting the server will probably result in a lost session making the whole rant unnecessary in the first place.

Bob:

See:

http://www.experts-exchange.com/Programming/Languages/.NET/ASP.NET/Q_23108345.html

how did you know that existed? that's kind of nuts

What about error reporting??

Steve:

Oh, I've seen this type of chatterbox before. This type of chatterbox is not the best at writing actual code but is great at making excuses as to why it's OK to not write the code. Long rambling comments that basically amount to "I should be doing some real work here but it's awfully tricky so here is an unnecessarily verbose explanation as to why it's OK to skip it so I can get on with something simple like making icons". This type of chatterbox is easily identified by the ratio of functional lines to commented lines, as well as the vacant look on his face. His most commonly used design pattern is:

// TODO

FTFY

TRWTF is his continued use of "//" instead of using "/* ... */" blocks.

seriously:

Bob:

See:

http://www.experts-exchange.com/Programming/Languages/.NET/ASP.NET/Q_23108345.html

how did you know that existed? that's kind of nuts

google it you fucking moron.

what are you talking about:

seriously:

Bob:

See:

http://www.experts-exchange.com/Programming/Languages/.NET/ASP.NET/Q_23108345.html

how did you know that existed? that's kind of nuts

google it you fucking moron.

Easy tiger.