The Daily WTF: Curious Perversions in Information Technology

2010-09-02 Reply Admin

boog:
highphilosopher:
boog:
wtf:
boog:
A bug isn't a WTF?

Nope.
I should rephrase.

"A bug can't be a WTF?"

That's better. Continue.

Actually no. You would think it would, but a bug is a failure on the part of the developer, and a WTF is something Worse Than Failure. This implies that it's not just a failure which a bug is.

Given your overly generic definition of a bug*, you're saying that a failure on the part of the developer is never "a WTF?"

My "nope" was "no, a bug is not necessarily a wtf". Certainly there are plenty of "holy cats, what on earth was that guy thinking" moments that are also bugs - but there are plenty of bugs that are just bugs - you say "oops", you fix them, they go away, done. And there are plenty of examples of working code that make a reasonable person's eyes bleed when they look at the source. I know two people who work in MUMPS, and the stuff they describe would make you weep, rend garments, gnash teeth, and so forth, but the stuff does what it's meant to.

So a bug is not necessarily a wtf, though it can be, and a wtf is not necessarily a bug, though it can be.

Okay?

(captcha is "appellatio", which is either a very literate sex act of the name of a manservant in a very posh sort of manor, or both)

2010-09-02 Reply Admin

frits:
wtf:
frits:
Two things: 1. "Worse Than Failure" is a backronym. I think we all know what WTF stands for.

"Backronym"? Thanks very much, I just vomited. I hope you're happy with yourself. Most of it went in the trash can. Bastard.

It's a real word, Wikipedia told me so.

Ow. That phrase seems to have set off a migraine. Not a good day to be me. Maybe I'll go delete Wikipedia. It won't last, but maybe it'll help.

2010-09-02 Reply Admin

That's just bloat within a method; I was expecting a 5-level hierarchy of decorators on top of a base implementation of AbstractBeanFactoryConstructorIterator. And reflection. And modifying bytecode. And aspect-oriented cross-cutting every which way.

Oh wait, what language is this again? Oops... I guess complexity is a lot less, err, complex in the C#/.NET world. :)

frits · 2010-09-02 Reply Admin

wtf:
frits:
wtf:
frits:
Two things: 1. "Worse Than Failure" is a backronym. I think we all know what WTF stands for.

"Backronym"? Thanks very much, I just vomited. I hope you're happy with yourself. Most of it went in the trash can. Bastard.

It's a real word, Wikipedia told me so.

Ow. That phrase seems to have set off a migraine. Not a good day to be me. Maybe I'll go delete Wikipedia. It won't last, but maybe it'll help.

Your advanced sarcasm spotter (ASS for short) is defective. Or is mine? I can't tell anymore.

2010-09-02 Reply Admin

frits:
wtf:
frits:
wtf:
frits:
Two things: 1. "Worse Than Failure" is a backronym. I think we all know what WTF stands for.

"Backronym"? Thanks very much, I just vomited. I hope you're happy with yourself. Most of it went in the trash can. Bastard.

It's a real word, Wikipedia told me so.

Ow. That phrase seems to have set off a migraine. Not a good day to be me. Maybe I'll go delete Wikipedia. It won't last, but maybe it'll help.

Your advanced sarcasm spotter (ASS for short) is defective. Or is mine? I can't tell anymore.

I think that's one point to me, then.

And watch what you say about my ass.

2010-09-02 Reply Admin

wtf:
boog:
highphilosopher:
boog:
wtf:
boog:
A bug isn't a WTF?

Nope.
I should rephrase.

"A bug can't be a WTF?"

That's better. Continue.

Actually no. You would think it would, but a bug is a failure on the part of the developer, and a WTF is something Worse Than Failure. This implies that it's not just a failure which a bug is.

Given your overly generic definition of a bug*, you're saying that a failure on the part of the developer is never "a WTF?"

My "nope" was "no, a bug is not necessarily a wtf". Certainly there are plenty of "holy cats, what on earth was that guy thinking" moments that are also bugs - but there are plenty of bugs that are just bugs - you say "oops", you fix them, they go away, done. And there are plenty of examples of working code that make a reasonable person's eyes bleed when they look at the source. I know two people who work in MUMPS, and the stuff they describe would make you weep, rend garments, gnash teeth, and so forth, but the stuff does what it's meant to.

So a bug is not necessarily a wtf, though it can be, and a wtf is not necessarily a bug, though it can be.

Okay?

(captcha is "appellatio", which is either a very literate sex act of the name of a manservant in a very posh sort of manor, or both)

Actually, your "nope" was quite right. I was wrong, originally. Hence my re-wording.

You and I are saying the same thing: not all bugs are WTFs, but some are. I get that. No confusion there. The original guy I replied to (way back when) and highphilosopher seemed to assert that bugs and WTFs are mutually exclusive (see his post if you don't believe me), which is downright bonkers. I was merely prodding them for clarification.

2010-09-02 Reply Admin

informatimago:
Indeed. I would go so far as having a look at the requirements.
Probably they were:

The accounts should be set:

when automation is disabled,

when automation is enabled and:

the account code is null or the empty string,

or when there is an account code.

Probably the analyst then expleted:

Then they should be set always!?

But the PHB replied:

No, no, look, the accounts should be set only:

when automation is disabled,

when automation is enabled and:

the account code is null or the empty string,

or when there is an account code.

and then added: "I'm a people person! I know how to deal with people! You take care of the computer!"

Look, 15 pieces of flair is the minimum, mm-kay? We're just asking you to express yourself a little more, that's all.

2010-09-02 Reply Admin

Quick rewrite:

private void SetRequisitionItem(RequisitionData.RequisitionItem requisitionItem, AccountData.Account account) { if(account == null) return; requisitionItem.AccountID = account.ID; requisitionItem.AccountCode = account.Code; }

Changes:

All branches set the boolean to true, so I removed all branches that dealt solely with setting boolean. Since the boolean is always true, there's no need for it. Just set the values. Instead of nesting all the code inside a != null, I inverted the if and skipped out. I removed the boolean from the method protocol. I renamed the method. You're not setting the account: you're setting the requisition item ;)

One question: did the code originally do something more complex, but then got morphed into this monstrosity?

Also, haven't they ever heard of ReSharper? It would have figured this all out and turned your code into what I said.

hatterson · 2010-09-02 Reply Admin

Vince:
Quick rewrite:
private void SetRequisitionItem(RequisitionData.RequisitionItem requisitionItem, AccountData.Account account) { if(account == null) return; requisitionItem.AccountID = account.ID; requisitionItem.AccountCode = account.Code; }

Changes:

All branches set the boolean to true, so I removed all branches that dealt solely with setting boolean. Since the boolean is always true, there's no need for it. Just set the values. Instead of nesting all the code inside a != null, I inverted the if and skipped out. I removed the boolean from the method protocol. I renamed the method. You're not setting the account: you're setting the requisition item ;)

One question: did the code originally do something more complex, but then got morphed into this monstrosity?

Also, haven't they ever heard of ReSharper? It would have figured this all out and turned your code into what I said.

So you're not only changing the function name you're also changing the number of parameters and leaving out an additional function call (IsAccountCodeNull())

Have fun fixing the rest of the code that these changes may have broken.

At the simplest this could be

if (account == null) return requisitionItem.IsAccountCodeNull(); requisitionItem.AccountID = account.ID; requisitionItem.AccountCode = account.Code;

2010-09-02 Reply Admin

G:
The Nerve:
private void SetAccount(RequisitionData.RequisitionItem requisitionItem, 
                        AccountData.Account account)
{
	requisitionItem.AccountID = account.ID;
        requisitionItem.AccountCode = account.Code;
}
That is assuming requisitionItem.IsAccountCodeNull() has no side effects (And the same for the various comparison operators - if they have been overloaded - in the original code)

Any application that has overloaded its comparison operators to have side effects would have plenty of worse WTFs in it than this function.

2010-09-02 Reply Admin

Alex:
So why does he start off with "architectural complexity" and large projects etc. and then all this is is some unnecessary code, which is either a leftover nobody dares fix or some misguided attempt to foresee the future? Where's the architectural complexity here? Where are the layers upon layers upon layers that are not needed?

It points out that this is just one example. By itself, I'd agree. It's not that much of a WTF. But if this is just an example of what all the code is like in a complex project with layers upon layers of functions as concisely written as this one, then I can certainly picture how the codebase as a whole could be a huge WTF.

2010-09-02 Reply Admin

frits:
2. The code in the article is no more a bug than an inefficient algorithm is a bug. A bug just means an unexpected or incorrect result. This code is just an example of superfluous logic.

It's only superfluous logic if it's actually correct. But it looks more likely that the code is returning the wrong result in many cases. If the comment in the code correctly states what it's trying to do, then the checks aren't superfluous; they need to be done in order to return true in some cases and false in others. The fact that they're actually returning true either way is a bug.

Well, removing the "superfluous" logic would at least make it more obvious that those checks aren't being done in a useful manner as intended. It might make the bugs (if that's what they are) easier to recognize.

2010-09-02 Reply Admin

Except that if FILE_NOT_FOUND is non-zero, then the rest of the ELSE IF statements will never be evaluated. "if (42)" should be at the top of the block.

:)

2010-09-02 Reply Admin

LB:
It points out that this is just one example. By itself, I'd agree. It's not that much of a WTF. But if this is just an example of what all the code is like in a complex project with layers upon layers of functions as concisely written as this one, then I can certainly picture how the codebase as a whole could be a huge WTF.

That was my point. If the problem with the code is the architectural complexity, why not show that? Like someone else already said, show us the aspects cross cutting whichever way they want. Show us the sixteen decorators around SomeClassWithARidiculouslyLongNameForClarityAndDocumentingPurposes.

Instead, we get a simple example of some code that was just a leftover nobody dared fix or a misguided attempt to forsee the future. Sure, a small WTF, but has nothing to do with the architectural stuff the article laid out at first.

2010-09-02 Reply Admin

True genius!

TheJasper · 2010-09-03 Reply Admin

C:
TheJasper:
no. ++x x++ may behave very differently.
http://en.wikipedia.org/wiki/Increment_operator#Increment_operator

I prefer x++ simply because it is the most used form. Even if you think ++x is better you should assume the next programmer is a self taught programmer who learned [c|Java|C#|...] from a ... for dummies book last night while waiting for his illegal porn torrents to finish downloading.
Well, that's a bit beside the point, since i was talking about /instructions/, not out-of-context expressions, and those would obviously discard the "result".

But now that you've mentioned the subjectivity of that choice, i really like the "++x" form, since it doesn't need to save the "pre" value and pass it as result. The memory and speed saves are minimal, i concede, but why choose waste simply because "everybody else does it"? :) I fail to see the relevance of that "self-taught" "next guy": if he doesn't know of preincrementing, he should learn about it.

Basing this choice on speed of processing is what I would call premature optimilization. The point of the choice I make is maintainability. The next guy may actually be an ok programmer just not a great programmer. Maintainable code is always better than code which is theoretically better. I'm not saying you have to write things poorly, I'm just saying some choices are unfortunate but better for maintainability.

Cbuttius · 2010-09-03 Reply Admin

If you are iterating through a C++ collection using a loop you should always use ++iter rather than iter++, because the latter will make an unnecessary copy of an object.

Remember that C++ has operator overloading. Pre-increment is

T& operator++()
{
  inc();
  return *this;
}

Post-increment is

T operator++(int)
{
  T copy(*this);
  inc();
  return copy;
}

where inc() is whatever is necessary to advance by one.

MarkJ · 2010-09-03 Reply Admin

SwampJedi:
by:
That's what you get when you have scientists coding.
"If this statement was correct, the following would happen. This statement is not correct, therefore it will not."

Electronics engineers, but I agree. It was very ad-hoc. I suppose the thought was "Oh, it's just software, we can do that."

The WTF in that "thought" is that anything is "just software". We all know how that attitude causes things that come back to bite us later - sometimes much later.

2010-09-04 Reply Admin

} finally {
  allowSetAccount = true;
}

2010-09-04 Reply Admin

frits:
wtf:
frits:
wtf:
frits:
Two things: 1. "Worse Than Failure" is a backronym. I think we all know what WTF stands for.

"Backronym"? Thanks very much, I just vomited. I hope you're happy with yourself. Most of it went in the trash can. Bastard.

It's a real word, Wikipedia told me so.

Ow. That phrase seems to have set off a migraine. Not a good day to be me. Maybe I'll go delete Wikipedia. It won't last, but maybe it'll help.

Your advanced sarcasm spotter (BUTT for short) is defective. Or is mine? I can't tell anymore.

FTFY

Randy Snicker · 2010-09-04 Reply Admin

frits:
wtf:
frits:
wtf:
frits:
Two things: 1. "Worse Than Failure" is a backronym. I think we all know what WTF stands for.

"Backronym"? Thanks very much, I just vomited. I hope you're happy with yourself. Most of it went in the trash can. Bastard.

It's a real word, Wikipedia told me so.

Ow. That phrase seems to have set off a migraine. Not a good day to be me. Maybe I'll go delete Wikipedia. It won't last, but maybe it'll help.

Your advanced sarcasm spotter (ASS for short) is defective. Or is mine? I can't tell anymore.

Oh you people with your four short-ass defects!

2010-09-05 Reply Admin

i hate seeing stuff that reminds me of my own occasional bad code.

2010-09-07 Reply Admin

I can almost guarantee that the code had control paths that set it to false in the past, but the that the requirement changed over time causing programmers to go in and change them to true one after another, until it ended up in its current state.

2010-09-07 Reply Admin

Well, if your performance is measuremed in lines-of-code, then code like this just flows naturally.

2010-09-09 Reply Admin

Coder:
Well, if your performance is measuremed in lines-of-code, then code like this just flows naturally.

2010-09-13 Reply Admin

Even if the compiler optimizes it away, it still adds unnecessary complexity and strain on the compiler

2010-09-24 Reply Admin

http://www.sofunjerseys.com

2012-03-06 Reply Admin

It's likely the code originally had both true and false sets, but was modified (either by a developer for debugging/testing purposes, or by a nub who didn't understand it, or as the result of a defect).

Accounting for Complexity

Leave a comment on “Accounting for Complexity”