- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Admin
I'm not a Java programmer, so I may need to ask Nagesh about this, but according to http://www.javaperformancetuning.com/, "String.equalsIgnoreCase is a lot faster than String.equals when the majority of the compared data have different lengths because equalsIgnoreCase first checks the length of the two strings." Maybe he's just in the habit of using that method and I assume since it breaks out when the length differs, there's not much of a speed impact.
Admin
Admin
TRWTF is that this method has enough stupid-looking little details to obscure the fact that the network I/O is happening on the main thread. I'm sure the user experience on a slow connection is wonderful.
Also, client-side hashing of the password. What are the odds that StaticUtils.md5() generates a random salt, applies it while hashing the password a few hundred times, and returns the concatenation of the salt and the final hash? What are the odds that it runs MD5 once without a salt and returns that? Yeah...
Admin
I can't believe no one found the real error in here: userString.matches("[a-zA-z0-9_]*")
They're allowing "[]^`" in the username.
Admin
Its so mind bendingly bad yet logical it is almost a beautiful WTF.
Admin
I've discovered serious deficiencies in my code, due to the fact I wasn't even aware that empty string ("") was mixed case.
Admin
equalsIgnoreCase() does indeed check for the length first, and if your strings start with the same characters, there could be a difference in speed.
However, one has to realise that equals() and equalsIgnoreCase() are two very different beasts. equals() takes an Object as a parameter, so you can invoke the equals() method on a String and pass a JAXBContext as a parameter (or indeed, the other way around). equalsIgnoreCase always takes a string as a parameter.
But more importantly, comparing against an empty string is silly, because you can get the length() of the string and compare it with 0, or if you're using Java 6 or later, you can invoke the isEmpty() method on a string.
Admin
I think it's more like, what weren't they thinking. If it was nicer it would check everything, and generate a list of errors.
Could be a lot worse, broken, enterprisie, or broken and enterprisie. The writer could have used this as an excuse to add a couple of new classes to the code base, but didn't. Instead he wrote some unimaginative procedural code to solve an unimaginative procedural problem.
Admin
It's still an extremely disgusting piece of crap.
If you do indeed think it's just "not particularly pretty", you prolly have a lot of WTF of your own writing to submit.
Admin
Delphi.
Admin
I will not tolerate anymore of this ultra-tolerance.
Admin
I'm not sure how that API works, but * matches zero or more characters, so I would have guessed that would match any string. (Although the match itself might be an empty string.)
Admin
Is this an example of poor code?
Yes.
Is this an example of a WTF? Not really.
It looks like a cut and past script job done by someone who either does not fully understand what they are doing, or can't be bothered to try. But you can still understand what's going on. He's taking values from a form, and trying to perform some validation against them. Aside from stupid things like calling the ToSting() method on the text input (Hint...it's already a string why make it an extra stringy string), and the tolower() on numerics etc... there is nothing monumentally stupid or worth of a jaw dropping HUH?
If he had done something like created his own string class because he thought that the existing string class would not handle all the values users could input for strings, or sent all the input to an XML file, and then had a service validate it and send it back etc.. then you would be looking at WTF quality code.
This is just an example of poor coding style. If the article submitter thinks this is stinky messy WTF code, then he's led a very sheltered life and needs get out some more.
Admin
On my keyboard, the top-row keys unshifted are: ²&é"'(-è_çà)= and shifted: ~1234567890°+
And if I turn on the up-arrow padlock, they swap...
Other people don't have your computer.
Admin
Hint: it's not String.
Admin
Admin
They used a Visual Studio Add-In to submit a Java article?
Admin
But you did stay at Holiday Inn Express last night?
Admin
Um, if you're going to use a BufferedReader, you might as well call readLine() to get the whole line instead of going character by character.
TRWTF is people who diss a language or library out of ignorance.
Admin
TRWTF is why a java snippet was sent via the "Visual Studio Add-in"
Admin
I believe that the CAPTCHA for each new commenter should be a one-line replacement for the horrific code-of-the day.
I admit, this would create a whole new subsytem of DailyWTF that could be written in oh-so-many ways. Perhaps each submission could be voted upon for correctness, and then validated by Amazon Mechanical Turk workers for semantic correctness (as there are some things a computer just cannot do).
The shortest, or most elegant entry would win a bebe gun and a number of bebes equal to the number of characters (ASCII only, please) in her/her answer.
An additional prize would be awarded if the winner were able to locate and wound the perpetrator, hopefully in the area of his/her fingers. It would be pointless to aim at the head, as it has already been demonstrated to be useless.
Admin
If I run this a million years, will it eventually read Shakespeare?
Admin
It makes sense to test the password & confirm contents before their equality. If not the user experience would be "confirm does not match password, please correct". Then after the user corrects it would tell it that the caracters are invalid. That would be stupid. The other way around saves the user some operations. Same goes for length. Ideally of course all problems should be displayed at once.
TRWTF is submitting Java code with the Visual Studio add-in.
Admin
"else if (!passString.matches("[a-zA-Z0-9]*") || passString.length() < 6)"
If you're already using a regex (clearly a inefficient for a simple check like this, but if you are), you may as well do !passString.matches("[a-zA-Z0-9]{6,}") and avoid the second check.
Admin
Can't put base64 data in my password? THIS SUCKS!
Admin
Wow! Through all of this people will allow email addresses to be entered without any type of domain suffix... so I can register as DWTF@DWTF and it's ok.
Admin
Admin
I tend to agree some what. I've made better validation but not by much. I tend to adhere to DRY and make very good use of things such as arrays, switches and OO. Also, I wouldn't regex check the pass string. It's not terrible as far as I can see. A few tweaks and it would be acceptable. I've seen much worse.
Admin
Since it's check minimum length (I would just swap comparisons otherwise) I wouldn't bother to optimise like that. If the input data is rarely less than six characters it might actually end up slower, not that you would notice though.
You have a lot to learn about optimisation. All you can really be sure of by doing what you suggested is that the code will be a little bit smaller.
Admin
+1, -1
It makes sense to check the contents of the password before comparing it against the confirm string, for the reason you say, and if the confirm string was different there's a fair chance that the user will end up correcting it as part of correcting the password.
But the confirm shouldn't ever be checked for matching the password rules, it should only ever be checked for matching the password.
Admin
Why on earth can I only use alphanumeric characters in my password?
Admin
Hmm....maybe I COMPLETELY missed the point of the WTF, but I don't get it. User is not logging in. User is submitting an initial set of credentials, and the app wants to produce an error if there password is not of the correct format (regex) or doesn't match (string compare). Regardless of the order, based on that requirement, BOTH commands need to be checked. Does it really matter which order? Seriously? If someone F'd up the entry, they have to redo anyways...
Admin
If you think that that's filthy code then consider yourself lucky to have a job in this area.