• JSGuru (unregistered)

Associated the radio group with the name of the variable it gets assigned would have helped. Or worse case, sequentially numbering the radio groups via a counter.

'Analysis? We don't need no stinkin' analysis!'

• JimmyCrackedCorn (unregistered)

TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

• Douglas (unregistered)

3333, not 2500.

1/(1-(9998./9999)**3) = 3333.3334

• ANON (unregistered) in reply to JimmyCrackedCorn
JimmyCrackedCorn:
TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

Why are radio buttons a WTF? Just because there are people not capable to use them properly?

Then boolean and regex are also WTFs.

• Will (unregistered)

Of course it is a WTF, they should of used a GUID.

• Racemaniac (unregistered) in reply to Douglas
Douglas:
3333, not 2500.

1/(1-(9998./9999)**3) = 3333.3334

it's 1/(1-((9998./9999)(9997/9999)(9996/9999))) = 1666

• Migala (unregistered) in reply to Douglas
Comment held for moderation.
• MathMagic (unregistered) in reply to Douglas

1667, not 3333, not 2500.

Chance of not using any number twice: P_good = (10000 / 10000) * (9999 / 10000) * (9998 / 10000) * (9997 / 10000) = 0.99940011

Chance of using at least one number twice or more often: P_bad = 1 - P_good = 0.00059989 = 1 / 1666.9722615785

TRWTF is statistics.

• MathMagic (unregistered) in reply to MathMagic

Bugger, used 10000 instead of 9999 and other guys were faster ;-)

• QJo (unregistered) in reply to JimmyCrackedCorn
JimmyCrackedCorn:
TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

From which fount of wisdom gushes this invigorating cup of advice? Is it a similar place to "don't use tabs, use spaces"?

The real WTF is paying attention to so-called guru sites which pontificate on best practices without expounding as to why. If a reason is provided, then one is able to glean some understanding of whether the advice is relevant and appropriate to the page in question.

• ABBA (unregistered)

I don't even read the stories anymore. I just come straight to the comments. If there's one thing I've learnt from the internet is that reading and/or understanding something just hinders your ability to effectively criticise it.

• JimmyCrackedCorn (unregistered) in reply to ANON

The use of radio buttons are ok as a visual choice, but it is their implementation in HTML that suck, as well as making it harder for developers to make them work correctly.

• CodyMonkey (unregistered)

The real wtf is not spend 4 minutes looking into the code when people keep complaining about faults..

• Mike (unregistered)

TRWTF is trying to find a bug without access to the code!

• Sunil Sdlavrot (unregistered)

TRWTF is using JS for this.

• ZoomST (unregistered) in reply to CodyMonkey
CodyMonkey:
The real wtf is not spend 4 minutes looking into the code when people keep complaining about faults..
So do you have enough knowledge about the size of the code base and how convoluted (as in fucked) it is to estimate 4 minutes, or are you making it up like the Marketing department? I bet it's the second choice.
• (cs)

int HashFunction(void* pObjectToHash) { return rand(); }

• Björn (unregistered)

The real WTF is using numbers at the beginning of ids.

• JimmyCrackedCorn (unregistered) in reply to QJo
QJo:
JimmyCrackedCorn:
TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

From which fount of wisdom gushes this invigorating cup of advice? Is it a similar place to "don't use tabs, use spaces"?

The real WTF is paying attention to so-called guru sites which pontificate on best practices without expounding as to why. If a reason is provided, then one is able to glean some understanding of whether the advice is relevant and appropriate to the page in question.

The use of radio buttons are ok as a visual choice, but it is their implementation in HTML that suck, as well as making it harder for developers to make them work correctly. There, potification with explanation.

• (cs) in reply to JimmyCrackedCorn
JimmyCrackedCorn:
The use of radio buttons are ok as a visual choice, but it is their implementation in HTML that suck, as well as making it harder for developers to make them work correctly. There, potification with explanation.

<pedantry>Then it's not a design issue, it's an engineering issue.</pedantry>

• (cs) in reply to QJo
QJo:
JimmyCrackedCorn:
TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

From which fount of wisdom gushes this invigorating cup of advice? Is it a similar place to "don't use tabs, use spaces"?

The real WTF is paying attention to so-called guru sites which pontificate on best practices without expounding as to why. If a reason is provided, then one is able to glean some understanding of whether the advice is relevant and appropriate to the page in question.

Here is a good blog post that explains why radio buttons are a better choice than dropdown lists.

• faoileag (unregistered)
(Bjørn) also never had a chance to look at a certain script used by the application: the mysterious custom.js
And why not? Is the script run through an obfuscator before being served to the general public? Or is Bjørn simply not capable of cutting & pasting together the right url to request only that script through his browser? And why is it that the person tasked with maintaining a web-application does not have access to the files with the javascript driving that web-application?

captcha: ideo. I have no ideo why custom.js should remain a mystery.

• Oliver (unregistered)

• faoileag (unregistered)

Looking at that generator code again... radio buttons are nice, but if you can't retrieve the value that's stored in their state, they are just a complete waste of browser window real estate.

You could probably try to get the buttons via the labels immediately trailing them, but that would make for rather brittle logik, I think (not to mention bad performance).

I would really like to see the web-app that's driven by that code...

• faoileag (unregistered)

And finally... that's regular expressions that's stored in the values:

`^something\$`
Nothing wrong with that, of course, but still... weird.

JimmyCrackedCorn:
TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.
If you only have a few options, it's less trouble to have all the options displayed. I hate comboboxes that say credit card type, only to have Visa and Other as options.

You're really just trying to avoid page-scroll with comboboxes. It takes an additional click to make an entry in a combobox.

JimmyCrackedCorn:
QJo:
JimmyCrackedCorn:
TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

From which fount of wisdom gushes this invigorating cup of advice? Is it a similar place to "don't use tabs, use spaces"?

The real WTF is paying attention to so-called guru sites which pontificate on best practices without expounding as to why. If a reason is provided, then one is able to glean some understanding of whether the advice is relevant and appropriate to the page in question.

The use of radio buttons are ok as a visual choice, but it is their implementation in HTML that suck, as well as making it harder for developers to make them work correctly. There, potification with explanation.

What, having shared group names? I suppose you could put them in a div and somehow work out that's a group. However, do you really need a groupbox around every set of radio buttons?

• (cs)

I have a similar issue with a web app we develop that might have to, in theory (if it was flexible enough), generate the same HTML code multiple times on the same page. Of course IDs are hard coded and the code uses .innerHTML to generate the code and .getElementById to retrieve references to elements. Once you generate a second copy of the HTML everything breaks.

My own code uses classes for all CSS-styling, uses DOM-style generation and retains references to critical nodes it'll need later, and uses a UID generator to generate any IDs I DO need.

That web app has all sorts of WTFs that would be good for this site, including a drag-and-drop module that attempts to poorly partly recreate the DOM hierarchy for drag and drop (by having coders manually declare all drop regions as HTML elements and bounding regions), all so that it can put a "dragging this thing" image under the cursor and figure out what's behind it based on X/Y coords (since e.target only returns the image). Has to support IE so no pointer-events: none;

I personally would have just generated a custom .cur for each image they wanted in front of the cursor. But that would have been far easier.

• Krunt (unregistered) in reply to faoileag
faoileag:
(Bjørn) also never had a chance to look at a certain script used by the application: the mysterious custom.js
And why not? Is the script run through an obfuscator before being served to the general public?

It's javascript, its obfuscated the moment it's written.

See because javascript is a messy pile of sh!t to look at, even if it's "well written", which it seldom ever is.

I guess the general point I'm trying to convey is that javascript is a crap language.

• XXI (unregistered)
Comment held for moderation.
• EvilSnack (unregistered)

I'd have to grant this WTF about three stars out of five:

1. Yes, this algorithm/code/technology choice is WTFery, but only in this circumstance; in other places it could have been the best choice.

2. This code is WTFery, but you have to be an expert to see why.

3. The original coder was trying to be clever, but failed.

4. The reasons this will not work should have been obvious to anyone capable of finding the keys to type this code.

5. Kill it with fire!

CAPTCH nisl: "I'm hopin nisl only take a moment."

• QJo (unregistered) in reply to JimmyCrackedCorn
JimmyCrackedCorn:
QJo:
JimmyCrackedCorn:
TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

From which fount of wisdom gushes this invigorating cup of advice? Is it a similar place to "don't use tabs, use spaces"?

The real WTF is paying attention to so-called guru sites which pontificate on best practices without expounding as to why. If a reason is provided, then one is able to glean some understanding of whether the advice is relevant and appropriate to the page in question.

The use of radio buttons are ok as a visual choice, but it is their implementation in HTML that suck, as well as making it harder for developers to make them work correctly. There, potification with explanation.

By that logic, because of the processing overheads and danger of implementing an off-by-one error, the use of loops for iteration should be avoided, and instead the instructions to be executed should be written sequentially in the program.

• QJo (unregistered) in reply to JimmyCrackedCorn
JimmyCrackedCorn:
QJo:
JimmyCrackedCorn:
TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

From which fount of wisdom gushes this invigorating cup of advice? Is it a similar place to "don't use tabs, use spaces"?

The real WTF is paying attention to so-called guru sites which pontificate on best practices without expounding as to why. If a reason is provided, then one is able to glean some understanding of whether the advice is relevant and appropriate to the page in question.

The use of radio buttons are ok as a visual choice, but it is their implementation in HTML that suck, as well as making it harder for developers to make them work correctly. There, potification with explanation.

Oh, and while I'm about it, grammar fail:

1. It should be "The use (of radio buttons) is ok" - the number of the verb must agree with its subject, not just the noun which happens to be closest, which in this case is the word "buttons" in the qualifying clause (emphasised by me as being a separate linguistic entity by parenthesising it) "of radio buttons".

2. It should be "it is their implementation in HTML that sucks", a similar mistake but in the opposite direction. The subject of the verb "sucks" is in this case "(their) implementation", not "their". Compare: "The children are crying because their ball are lost", which exhibits the same error but in a more obviously incorrect context.

3. Finally, it should be "pontification" not "potification", but I will allow that this mistake may well be just a typo caused by carelessness rather than a genuine spelling mistake caused by ignorance.

• Pock Suppet (unregistered) in reply to ABBA
ABBA:
I don't even read the stories anymore. I just come straight to the comments. If there's one thing I've learnt from the internet is that reading and/or understanding something just hinders your ability to effectively criticise it.
You, sir, have discovered the secret to the internets, to politics, and to life! I expect to see you running for office next fall.
• Krunt (unregistered)

Oh snap! Better get Jimmy some ice for his BURRRRRN AM I RIGHT?

• Smug Unix User (unregistered)

Could have just used a custom javascript GUID solution. Did anyone win the coding competition?

• JayGee (unregistered)

I can't believe that no one else has criticized the stories use of the radio as if it has anything to do with radio buttons. It's not funny, not even slightly. It annoys me more than the code.

JayGee:
I can't believe that no one else has criticized the stories use of the radio as if it has anything to do with radio buttons. It's not funny, not even slightly. It annoys me more than the code.

I suppose after finally figuring out what the hell kind of pun that was; if I were to reread, I'd have to mentally overlook the pun or it would burn.

• Jeremy (unregistered)

So, he debugged it a few times, but never looked at the javascript that made a healthy portion of the page? He also didn't notice that those groups were named with random numbers?

• (cs) in reply to faoileag
faoileag:
(Bjørn) also never had a chance to look at a certain script used by the application: the mysterious custom.js
And why not? Is the script run through an obfuscator before being served to the general public? Or is Bjørn simply not capable of cutting & pasting together the right url to request only that script through his browser? And why is it that the person tasked with maintaining a web-application does not have access to the files with the javascript driving that web-application?

captcha: ideo. I have no ideo why custom.js should remain a mystery.

You misunderstood the phrase "had a chance to". In this case, it doesn't mean "had the ability to". Instead, it means "had a reason to". He could have looked at the file whenever he wanted, but he never looked at it because there was no reason for him to look at it.

• (cs)

TRWTF is not even bothering to look at the code when investigating a bug report. Trying to reproduce a problem is certainly a valid approach but by no means exhaustive. You can always try to think. Very poor.

• faoileag (unregistered) in reply to Krunt
Krunt:
faoileag:
(Bjørn) also never had a chance to look at a certain script used by the application: the mysterious custom.js
And why not? Is the script run through an obfuscator before being served to the general public?

It's javascript, its obfuscated the moment it's written.

See because javascript is a messy pile of sh!t to look at, even if it's "well written", which it seldom ever is.

Ever seen what some people do with C++? Not to mention C. You can create a messy pile of spaghetti code in most, if not all, languages if you don't give 1 cent for maintainability.

Krunt:
I guess the general point I'm trying to convey is that javascript is a crap language.
Care to highlight just why you think it is?

I actually enjoy programming with it. Some bits annoy me, true, but some bits also delight me and the overall comfort-factor ist definitely higher than with C. Or the good ole line-number-based BASIC-dialects of the mid-80s.

• JimmyCrackedCorn (unregistered) in reply to QJo
QJo:
JimmyCrackedCorn:
QJo:
JimmyCrackedCorn:
TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

From which fount of wisdom gushes this invigorating cup of advice? Is it a similar place to "don't use tabs, use spaces"?

The real WTF is paying attention to so-called guru sites which pontificate on best practices without expounding as to why. If a reason is provided, then one is able to glean some understanding of whether the advice is relevant and appropriate to the page in question.

The use of radio buttons are ok as a visual choice, but it is their implementation in HTML that suck, as well as making it harder for developers to make them work correctly. There, potification with explanation.

Oh, and while I'm about it, grammar fail:

1. It should be "The use (of radio buttons) is ok" - the number of the verb must agree with its subject, not just the noun which happens to be closest, which in this case is the word "buttons" in the qualifying clause (emphasised by me as being a separate linguistic entity by parenthesising it) "of radio buttons".

2. It should be "it is their implementation in HTML that sucks", a similar mistake but in the opposite direction. The subject of the verb "sucks" is in this case "(their) implementation", not "their". Compare: "The children are crying because their ball are lost", which exhibits the same error but in a more obviously incorrect context.

3. Finally, it should be "pontification" not "potification", but I will allow that this mistake may well be just a typo caused by carelessness rather than a genuine spelling mistake caused by ignorance.

Ok, mea culpa on the grammar - thanks for the lesson.

On the radio buttons - I still think their use produce way too many buggy web sites, and many developers resort to them when they could or should be using dropdown lists or combo boxes.

• I didn't consult a guru site for this hard won opinion - just 15 years of slogging through poorly designed sites.
• I wasn't trying to raise your ire, just trying to provoke thoughtful dialog.
• Captain Oblivious (unregistered) in reply to QJo
QJo:
JimmyCrackedCorn:
QJo:
JimmyCrackedCorn:
TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

From which fount of wisdom gushes this invigorating cup of advice? Is it a similar place to "don't use tabs, use spaces"?

The real WTF is paying attention to so-called guru sites which pontificate on best practices without expounding as to why. If a reason is provided, then one is able to glean some understanding of whether the advice is relevant and appropriate to the page in question.

The use of radio buttons are ok as a visual choice, but it is their implementation in HTML that suck, as well as making it harder for developers to make them work correctly. There, potification with explanation.

By that logic, because of the processing overheads and danger of implementing an off-by-one error, the use of loops for iteration should be avoided, and instead the instructions to be executed should be written sequentially in the program.

Loops should be avoided for those reasons. Recursion over an algebraic data type should be preferred instead.

• belzebub (unregistered)

Bjorne is probably typical lazy a**hole who'd never do anything more than exactly minimum required for not being fired yet. If he'd checked the code first time the issue was reported, it would be solved immediately.

I say: fire Bjorne!

• Anonymous Paranoiac (unregistered)

TRWTF is Systems Hungarian Notation in the function name. I would have never figured out that "fnCreateRadioButtons" was a function or that iLen was an integer without that extra bit of help. But what really annoys me is when the developer can't think of a meaningful prefix, but knows he must use something and just picks a random character, such as, say 'z' or 'x', even when they impart no meaning, which is worse than imparting clearly obvious meaning. For the record, I have no problem with judicious use of Application Hungarian Notation.

• Harrow (unregistered) in reply to QJo
QJo:
3. Finally, it should be "pontification" not "potification"...
Are you sure? I thought "potification" means explaining something complicated while under the influence of marijuana.

-Harrow.

• (cs) in reply to belzebub

belzebub...

If a complaint comes in every month or so, which says "Your website is broken... the pages don't work", then the complainant can fuck off, and not expect the bug to ever get fixed, until they describe it properly.

• Paul Neumann (unregistered) in reply to JimmyCrackedCorn
JimmyCrackedCorn:
* I wasn't trying to raise your ire, just trying to provoke thoughtful dialog.
Orly? It seemed there was a thoughtful dialog attempting occur. It appears this is an attempt to block dialog through a back handed rhetorical statement about fostering a dialog.

Ladies and gentlemen: I believe we have found the father of the president's daughter (and my ex-wife).

• faoileag (unregistered) in reply to eViLegion
eViLegion:
If a complaint comes in every month or so, which says "Your website is broken... the pages don't work", then the complainant can fuck off, and not expect the bug to ever get fixed, until they describe it properly
You do that once with a complainant that has enough clout (like the most valuable customer your company has, like the vice president's daughter, like the side-affair of your boss...) and you might find out that that policy of yours can make your life far more miserable than the one of the complainant.

Or to put it another way: complainants are customers and usually don't know heck about the terminology/jargon of (web)developers. They might use a browser without knowing what a browser is, is what I'm saying.

Or how would you feel if the garage attendant sends you away because "funny sounds from under the bonnet" is not a proper description of the problem your car is having?

You should take pride in being able to diagnose and fix a problem even without a proper problem description.

Sheesh, some people!