The Daily WTF: Curious Perversions in Information Technology

2014-03-11 Reply Admin

try { checkForwardEmail(); } catch (First t) { String msg = t.getMessage(); if (msg != null) { msg = msg + ""; System.out.println(msg); } }

slipstream · 2014-03-11 Reply Admin

Instead of catching a generic class, let's catch something EVEN MORE GENERIC!

2014-03-11 Reply Admin

slipstream:
Instead of catching a generic class, let's catch something EVEN MORE GENERIC!

If you don't understand generics, catch everything!

2014-03-11 Reply Admin

I wonder what the anonymous submitter replied to that...

2014-03-11 Reply Admin

Tip

Learn how to format a try/catch block correctly

2014-03-11 Reply Admin

TRWTF is that he's actually willing to learn and accept criticism. The second check in is probably a combination of lack of experience and bad/unspecific advice (anon obviously didn't explain why the things Joe did wrong were actually wrong)

2014-03-11 Reply Admin

This is BS. Now we're making fun of people that are unexperienced programmers? Pff, lame.

Until recently there was really bad code where you had to wrap your head around to get what was wrong. Now it's just newbies we're laughing about? I'm done here...

Severity One · 2014-03-11 Reply Admin

The real WTF is probably that a project manager is "helping" by submitting code into the repository, even though he knows nothing of Java.

2014-03-11 Reply Admin

I'm still wondering what was he hoping to achieve with msg = msg + "". Maybe some old reflex that got to him on some other development platform?

2014-03-11 Reply Admin

What I want to know is whether JIRA-381 had anything to do with this code, or with error handling. I.e., could Adolf have given advice which was a little more relevant.

OzPeter · 2014-03-11 Reply Admin

Tagging the code itself with the name of the bug that was fixed, and the name of the person who fixed it. Especially when you have a code repository.

2014-03-11 Reply Admin

TRWTF is that this was submitted at all.

2014-03-11 Reply Admin

Pista:
I'm still wondering what was he hoping to achieve with msg = msg + "". Maybe some old reflex that got to him on some other development platform?

It's an type-coercion idiom in Javascript, you ensure that msg is a string. So, yes, both "old reflex" and "other development platform" probably apply.

2014-03-11 Reply Admin

RFox:
TRWTF is that this was submitted at all.

It would be if only the first check-in had been submitted. However, the second check-in following the anonymous submitter's recomendations shows that CmdrJoe

has no idea whatsoever what a "descriptive and relevant" comment is.
is ignoring advice about not to pollute the codebase with bugtracking data.
has no idea what a "generic" exception is.

Furthermore, the line 'msg = msg + "";' is still in there, which is meaningless in Java as Java is a strongly typed language.

On the plus side, CmdrJoe did indeed something meaningfull when catching the exception, although error handling like "System.out.println(msg);" leaves some room for improvement.

2014-03-11 Reply Admin

OzPeter:
Tagging the code itself with the name of the bug that was fixed, and the name of the person who fixed it. Especially when you have a code repository.

Yeah, so I have to spend 5 minutes to find out basic information. Think about others, no-one cares about you.

Numpties and duvelopers, no wonder production DBAs are hated

2014-03-11 Reply Admin

1) If you need to add a comment, it should be descriptive and relevant to the code 2) The ticket number and your name are tracked by version control

Some comment is better than no comment and to be honest the code is pretty self documenting.
Sure it is, but it's much easier to see this way. We have a standard in our ERP system that requires us to document our name, date, and ticket number. That way it's simple to see as we're going through code to see what is base code and what is a modification.

Matt Westwood · 2014-03-11 Reply Admin

Oh yeah, I see TRWTF: he's mucked up the indentation.

2014-03-11 Reply Admin

Da Biggest @sshole:
OzPeter:
Tagging the code itself with the name of the bug that was fixed, and the name of the person who fixed it. Especially when you have a code repository.
Yeah, so I have to spend 5 minutes to find out basic information. Think about others, no-one cares about you.
Numpties and duvelopers, no wonder production DBAs are hated

Yeah, 5 minutes when you really need to find out who fixed a particular bug and when as opposed to spending your entire day scrolling through lines of "JIRA-NNNN Joe." I prefer my bug tracking data in the repository, thank you.

We have over 7000 items in Jira for just one of our products. I really don't need to wade through that many useless comments in the source code.

2014-03-11 Reply Admin

slipstream:
Instead of catching a generic class, let's catch something EVEN MORE GENERIC!

"catch(...){}"

Come on, who hasn't done that at least once.

Steve The Cynic · 2014-03-11 Reply Admin

Da Biggest @sshole:
OzPeter:
Tagging the code itself with the name of the bug that was fixed, and the name of the person who fixed it. Especially when you have a code repository.
Yeah, so I have to spend 5 minutes to find out basic information. Think about others, no-one cares about you.
Numpties and duvelopers, no wonder production DBAs are hated

The alternative view is that this sort of comment merely shows that on some date or other, some person or other made some change or other related to some ticket or other, the result of which is that the code looks like what it is now.

Thanks guys, I knew that. Now I have to dig for those five minutes to understand what the change was, if it is important in the context of what I'm doing in the code, and maybe things like whether someone else changed it afterwards, or before, or whatever; or what the problem was that provoked the ticket that provoked the change.

No. Don't do that. If the changed code has some level of fragility, or if there is a reason why it is like it is, explain that - in words, not ticket numbers - and only then give a reference to the ticket. (Finding out who made the change is of use primarily if you are playing the blame game, except when you need to ask the culprit (there's that blame game again) what his reasons were...)

2014-03-11 Reply Admin

Kevin:
1) Some comment is better than no comment and to be honest the code is pretty self documenting.

If something's really self documenting, no comment is better than any comment.

On the other hand, if that code was self documenting, there wouldn't be a discussion on what's its purpose here.

2014-03-11 Reply Admin

Kevin:
1) If you need to add a comment, it should be descriptive and relevant to the code

Some comment is better than no comment and to be honest the code is pretty self documenting.

That's definitely a no!!

To be "better" than no comment the comment needs to: a) provide more information than you can see at the first glance on the code (If the comment contains the same information than the code: how can it be "better" than no comment?) b) add correct information! (if the comment contains incorrect information, it definitely would have been better to leave it away completely)

2014-03-11 Reply Admin

Your Name:
"catch(...){}"
Come on, who hasn't done that at least once.

Had a coworker with a very special version of exception handling:

begin:
try {
   object.method();
} catch (Exception e) {
   goto begin;
}

I wish I would be exaggerating, but his programs were littered with these! Still having nightmares about this abomination...

2014-03-11 Reply Admin

faoileag:
Pista:
I'm still wondering what was he hoping to achieve with msg = msg + "". Maybe some old reflex that got to him on some other development platform?
It's an type-coercion idiom in Javascript, you ensure that msg is a string. So, yes, both "old reflex" and "other development platform" probably apply.

As always, TRWTF is Javascript.

balazs · 2014-03-11 Reply Admin

How do you comment if you have to fix a failed fix? When will the fix be part of the codebase thus comment loses importance? Who will remove it then? What will be the commit comment to explain it?

If you have JIRA and some other ALM tools, you might want to integrate them. There are products that will then show you a JIRA issue, what was committed to the repo to fix it, highlighting the changed lines. Easy. But you may want to stay at commenting changes in source and be TRWTF.

2014-03-11 Reply Admin

Your Name:
slipstream:
Instead of catching a generic class, let's catch something EVEN MORE GENERIC!

"catch(...){}"

Come on, who hasn't done that at least once.

public I still do it. It's usually faster than digging through the documentation for the library function you're calling, and if you don't have the library docs available at all it's just about the only thing you can do. In a multi-threaded server app a catch-all is better than letting an undocumented exception kill the whole app (which some implementations will do).

At the very least you can log that there was an exception and kill the thread. Then whoever has the task of doing something about the issue will have an indication of which function call threw the exception.

Steve The Cynic · 2014-03-11 Reply Admin

balazs:
How do you comment if you have to fix a failed fix? When will the fix be part of the codebase thus comment loses importance? Who will remove it then? What will be the commit comment to explain it?
If you have JIRA and some other ALM tools, you might want to integrate them. There are products that will then show you a JIRA issue, what was committed to the repo to fix it, highlighting the changed lines. Easy. But you may want to stay at commenting changes in source and be TRWTF.

The main problem is that whatever you put in place to ensure good information trails, people will subvert it if they are so minded.

No rules? People will submit checkins with no checkin comment, and comments like "fix problem" in the code.

No empty commit comments allowed? People will submit this comment:

.

Regexes to guarantee a minimal format? People will submit this comment:

Ticket 1234: .

(or whatever other minimal commit comment is required to pass the filter).

As I've said elsewhere, you can't fix stupid. You can't fix willfully subversive either, except by disciplinary procedures.

2014-03-11 Reply Admin

mortfurd:
We have over 7000 items in Jira for just one of our products. I really don't need to wade through that many useless comments in the source code.

Well, either you have millions of line of code (in which case 7000 comments will hardly be noticeable), or your company writes really buggy code if you're having to 'wade through' these comments...

2014-03-11 Reply Admin

Da Biggest @sshole:
OzPeter:
Tagging the code itself with the name of the bug that was fixed, and the name of the person who fixed it..
Yeah, so I have to spend 5 minutes to find out basic information. Think about others, no-one cares about you.

If you're not using Blame (or your VC-of-choice-equivalent-thereof) for this, you're doing it wrong.

ubersoldat · 2014-03-11 Reply Admin

Come on, the RealWTF is using XML for a freaking comment. I mean, XML!!!

Smitty · 2014-03-11 Reply Admin

Da Biggest @sshole:
Yeah, so I have to spend 5 minutes to find out basic information. Think about others, no-one cares about you.

If it takes you 5 minutes to find the history of a file in your VCS, you are TRWTF. These comments are pure line noise. Any half-decent VCS will show you who modified a line and even provide a nice graphical diff to the previous version at the touch of a button.

2014-03-11 Reply Admin

mkl:
Kevin:
1) Some comment is better than no comment and to be honest the code is pretty self documenting.

If something's really self documenting, no comment is better than any comment.

On the other hand, if that code was self documenting, there wouldn't be a discussion on what's its purpose here.

Why is there a discussion of the purpose of a try/catch?

It was pretty obviously intended to wrap a failing function. Everything else is implementation details, and we don't know what the called function does, so there's no point speculating.

Whether or not this is the appropriate place to stick this block is a different discussion entirely.

Snooder · 2014-03-11 Reply Admin

Smitty:
Da Biggest @sshole:
Yeah, so I have to spend 5 minutes to find out basic information. Think about others, no-one cares about you.

If it takes you 5 minutes to find the history of a file in your VCS, you are TRWTF. These comments are pure line noise. Any half-decent VCS will show you who modified a line and even provide a nice graphical diff to the previous version at the touch of a button.

Sure. Once you've ALREADY figured out which commit you need to find. If you are looking at something from two years, ago, there may be quite a few revisions to wade through before you get there. Whereas if the block of code you need to investigate is helpfully tagged with the ticket number and name of the person who wrote it, you can either look up the ticket or look up the person and get most of the information you need.

Steve The Cynic · 2014-03-11 Reply Admin

Snooder:
Sure. Once you've ALREADY figured out which commit you need to find. If you are looking at something from two years, ago, there may be quite a few revisions to wade through before you get there. Whereas if the block of code you need to investigate is helpfully tagged with the ticket number and name of the person who wrote it, you can either look up the ticket or look up the person and get most of the information you need.

Things like svn annotate(*) will get you there sooner. (And if there are N commits on the code in question, the original author may be unable to help, since you'd need to eliminate all the intervening changes as causes before you could annotate(**) him.

(*) or its more hostile cousin, svn blame. (**) See, I told you it was more hostile.

2014-03-11 Reply Admin

Kabi:
Your Name:
"catch(...){}"
Come on, who hasn't done that at least once.
Had a coworker with a very special version of exception handling:
begin:
try {
   object.method();
} catch (Exception e) {
   goto begin;
}
I wish I would be exaggerating, but his programs were littered with these! Still having nightmares about this abomination...

Abomination indeed. It should clearly have been

while (true) {
   try {
      object.method();
      break;
   } catch (Exception e) {
   }
}

2014-03-11 Reply Admin

Snooder:
Smitty:
Da Biggest @sshole:
Yeah, so I have to spend 5 minutes to find out basic information. Think about others, no-one cares about you.

If it takes you 5 minutes to find the history of a file in your VCS, you are TRWTF. These comments are pure line noise. Any half-decent VCS will show you who modified a line and even provide a nice graphical diff to the previous version at the touch of a button.

Sure. Once you've ALREADY figured out which commit you need to find. If you are looking at something from two years, ago, there may be quite a few revisions to wade through before you get there. Whereas if the block of code you need to investigate is helpfully tagged with the ticket number and name of the person who wrote it, you can either look up the ticket or look up the person and get most of the information you need.

I agree in principle, but again it depends on how it was done. Adding a comment at the top of a function with a change request adds no value and just clutters the code. However, if you have a complicated function and add a change request comment to an odd looking if-statement in the middle, that might help as you can see what problem said statement was added to solve. The same principle can be applied to adding requirement numbers to your code.

Yes, you can find out who added what by looking at version history. However, our code repository is about 10 years old and most of our files have 50+ revisions, some with 200+, talk about a needle in a haystack. Again, this is something that you can't apply a blanket statement to, it is more of a case-by-case basis.

2014-03-11 Reply Admin

Kabi:
Had a coworker with a very special version of exception handling:
begin:
try {
   object.method();
} catch (Exception e) {
   goto begin;
}

"The definition of insanity is doing the same thing over and over and expecting different results."

2014-03-11 Reply Admin

Kabi:
Your Name:
"catch(...){}"
Come on, who hasn't done that at least once.
Had a coworker with a very special version of exception handling:
begin:
try {
   object.method();
} catch (Exception e) {
   goto begin;
}
I wish I would be exaggerating, but his programs were littered with these! Still having nightmares about this abomination...

What language is this? Better yet, who was your coworker? Last time I checked, only Chuck Norris could use goto in Java...

2014-03-11 Reply Admin

ReverendBubba:
"The definition of insanity is doing the same thing over and over and expecting different results."

Call me insane then. I flipped a coin, heads. Then I flipped again... OMGWTF! Tails?!??

chubertdev · 2014-03-11 Reply Admin

Steve The Cynic:
balazs:
How do you comment if you have to fix a failed fix? When will the fix be part of the codebase thus comment loses importance? Who will remove it then? What will be the commit comment to explain it?
If you have JIRA and some other ALM tools, you might want to integrate them. There are products that will then show you a JIRA issue, what was committed to the repo to fix it, highlighting the changed lines. Easy. But you may want to stay at commenting changes in source and be TRWTF.
The main problem is that whatever you put in place to ensure good information trails, people will subvert it if they are so minded.

No rules? People will submit checkins with no checkin comment, and comments like "fix problem" in the code.

No empty commit comments allowed? People will submit this comment:

.

Regexes to guarantee a minimal format? People will submit this comment:

Ticket 1234: .
(or whatever other minimal commit comment is required to pass the filter).
As I've said elsewhere, you can't fix stupid. You can't fix willfully subversive either, except by disciplinary procedures.

Or you see these, from a person that preceded me:

-no me gusta. -interesting, very very interesting. -There you are, take THAT! -being very careful with [revision] -[revision] DEAD, something else, maybe. -dales dead bugs. -oops. -out with the old -in with the new -wack -stamp -stupid log message -ah geez

(yes, these are all real)

cellocgw · 2014-03-11 Reply Admin

Kabi:
Your Name:
"catch(...){}"
Come on, who hasn't done that at least once.
Had a coworker with a very special version of exception handling:
begin:
try {
   object.method();
} catch (Exception e) {
   goto begin;
}
I wish I would be exaggerating, but his programs were littered with these! Still having nightmares about this abomination...

Awww, c'mon: he clearly used this as a "Wait until the method works," loop. Some outside event will happen sooner or later to bring success.

2014-03-11 Reply Admin

Steve The Cynic:
balazs:
How do you comment if you have to fix a failed fix? When will the fix be part of the codebase thus comment loses importance? Who will remove it then? What will be the commit comment to explain it?
If you have JIRA and some other ALM tools, you might want to integrate them. There are products that will then show you a JIRA issue, what was committed to the repo to fix it, highlighting the changed lines. Easy. But you may want to stay at commenting changes in source and be TRWTF.
The main problem is that whatever you put in place to ensure good information trails, people will subvert it if they are so minded.

No rules? People will submit checkins with no checkin comment, and comments like "fix problem" in the code.

No empty commit comments allowed? People will submit this comment:

.

Regexes to guarantee a minimal format? People will submit this comment:

Ticket 1234: .
(or whatever other minimal commit comment is required to pass the filter).
As I've said elsewhere, you can't fix stupid. You can't fix willfully subversive either, except by disciplinary procedures.

Steve, all of those things can be controlled.

You: Your last 5 commit messages were ".", "lol", "NOT THE BEEEES", "fix" and "real fix". Developer: and? You: You're fired.

It's quite easy to ensure good quality processes, warn them first, if they don't mend their ways then give bad performance reviews (and hence pay rises and promotions), and ultimately, fire people if they still don't follow them.

TBH most commit hooks are for your benefit. Eg, if you don't add a case number in your commit, then your ticked doesn't get updated automatically, it doesn't get marked as ready for testing when deployed to test, and it doesn't get marked as done when released. The commit hook prevents you from having to do that work (and besides, our commit hooks are such that if you commit the same change twice with the same message, failed commit hook or not, it goes through)

2014-03-11 Reply Admin

Everybody is inexperienced at first, but when I was a neophyte programmer I read books and so on to improve my skills - I still do.

I've met programmers who had over a decade of experience in a language who didn't really understand the basics of that language, who thought that this particular code (which I see examples of every day in my current project) is fine and recommended.

2014-03-11 Reply Admin

TRWTF is that he didn't close the markup tag in the revised checkin.

2014-03-11 Reply Admin

Stark_:
TRWTF is that he didn't close the markup tag in the revised checkin.

<jira-382 comment="correct own comment"> Whoops, I guess he did. </jira-382>

Spectre · 2014-03-11 Reply Admin

Pista:
I'm still wondering what was he hoping to achieve with msg = msg + "". Maybe some old reflex that got to him on some other development platform?

His IDE was probably warning him that msg was an unused variable.

2014-03-11 Reply Admin

Snooder:
Smitty:
Da Biggest @sshole:
Yeah, so I have to spend 5 minutes to find out basic information. Think about others, no-one cares about you.

If it takes you 5 minutes to find the history of a file in your VCS, you are TRWTF. These comments are pure line noise. Any half-decent VCS will show you who modified a line and even provide a nice graphical diff to the previous version at the touch of a button.

Sure. Once you've ALREADY figured out which commit you need to find. If you are looking at something from two years, ago, there may be quite a few revisions to wade through before you get there. Whereas if the block of code you need to investigate is helpfully tagged with the ticket number and name of the person who wrote it, you can either look up the ticket or look up the person and get most of the information you need.

The revision tag(s) are in the bug log, duh. In most modern bug-trackers (I don't consider Bugzilla modern) they're integrated and can be clicked on to show the diff in question - along with the submitter, which should match the bug comment anyway. The commit message should also reference the bug if it was a specific fix. Seriously, stone age tools get you stone age inefficiency, it's time to upgrade.

2014-03-11 Reply Admin

anonymous:
ReverendBubba:
"The definition of insanity is doing the same thing over and over and expecting different results."
Call me insane then. I flipped a coin, heads. Then I flipped again... OMGWTF! Tails?!??

You didn't carry out your experiment far enough. If you flip it twice again, you will get heads, then tails again. This occurs in order to satisfy the "law of averages".

2014-03-11 Reply Admin

TRWTF is that someone named their product's project "JIRA" in the Jira.

Unless this is actually from the source code for Jira itself, in which case it would explain a few things.

PiisAWheeL · 2014-03-11 Reply Admin

My engineering friends taught me this about statistics...:
anonymous:
ReverendBubba:
"The definition of insanity is doing the same thing over and over and expecting different results."
Call me insane then. I flipped a coin, heads. Then I flipped again... OMGWTF! Tails?!??
You didn't carry out your experiment far enough. If you flip it twice again, you will get heads, then tails again. This occurs in order to satisfy the "law of averages".

Your argument is moot. What variables are in play when you flipped your coin? Did you start on the same side of the coin? How high did you flip it? what was the spin? The velocity? The windspeed? If you can duplicate those precisely, you should not expect a different result.

Also, Flipping a coin has a predetermined number of possibilities. If you flipped a coin, you will get heads or tails. If you flip the coin and the outcome is, say, Velociraptor, THAT would be insanity.

Knowing is Half the Battle

Leave a comment on “Knowing is Half the Battle”