• Tractor (unregistered)

    Frist!

    WooH!

  • draco malfoy (unregistered)

    When you move to a new town, someone has to be FRIST

  • Tractor (unregistered)

    Funny how the regex matches too if only one of the character is in the allowed range. The error message should be

    "Username must contain at least one alphanumeric characters or _"
  • ldam (unregistered)

    I always wondered about how to type those uppercase digits...

  • NerdF (unregistered)

    I like how it only cares about one cause of fail...

  • (cs)

    Holy "Magic Button"!

  • RRR (unregistered)

    This is a very LAME submission. There are prioritized error codes returned for each test. How else could it be done if not like that? Please don't touch the code in that function! You clearly have no clue what and why it does what it does. And, please, uninstall your Submit-to-WTF Visual Studio Add-In! It encourages trigger happy WTFers to submit crappy TDWTF entries...

  • alyf (unregistered) in reply to Tractor

    It doesn't.

    In Java (well, ok, Android...) String.matches() always tests the whole input against the regex.

  • anon (unregistered)

    TRWTF is catch (Exception e) { e.printStackTrace() }.

    Should be catch (Exception e) { error = 11 }

  • less-than-less-than-filthy (unregistered)

    Yawn. If this is an example of filthy and monstrous to you, I think you better get your job back at reputable $company_name and don't travel far from home ever again.

  • asdf (unregistered)

    I particularly like when they use result.equalsIgnoreCase on a bunch of numbers. Gotta watch out for those uppercase 2s!

  • Anoniempje (unregistered) in reply to RRR

    Somebody sounds like a sad panda!

  • (cs) in reply to alyf
    alyf:
    It doesn't.

    In Java (well, ok, Android...) String.matches() always tests the whole input against the regex.

    So on Android-Java "[0-9]" and "^[0-9]$" are effectively the same thing?

    (Hint: they shouldn't be. The first looks for at least zero digits somewhere, so should match any string whatsoever, while the second will match any string (including the empty string) that contains no non-digits.)

  • You can't handle my name! (unregistered) in reply to asdf

    Also on empty strings. Clearly cut'n'paste-coding.

    But it works, so why spend time "fixing" it?

    TRWTF is quoting "password" when there is no variable actually named "password".

  • kjordan (unregistered) in reply to asdf
    asdf:
    I particularly like when they use result.equalsIgnoreCase on a bunch of numbers. Gotta watch out for those uppercase 2s!
    I also like the equalsIgnoreCase on empty string. Got to watch out for those case-sensitve empty strings ;)
  • DTrain (unregistered) in reply to RRR

    I have to agree. This is not particularly pretty code, but it's hardly "Oh God, what were they thinking?!" code.

  • Uncle Code Monkey (unregistered)

    Ignoring the try/catch that eats all Exceptions (they forgot to also eat all Errors!)...

    Way to use R.string.dialog_title_oops for the dialog title but then proceed to put hard coded strings for all of the messages.

    I agree with others commenting, this is a weak WTF. Could it stand to be improved? Certainly. WTF-worthy? imo, no.

  • Drilnoth (unregistered)

    There only needs to be one set of if/then statements...

    Bah! The entire error variable is unnecessary!

    Captcha: genitus. Sounds like a disease that causes genius. Shame whoever wrote this code didn't have it.

  • blueg3 (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    So on Android-Java "[0-9]*" and "^[0-9]*$" are effectively the same thing?

    (Hint: they shouldn't be. The first looks for at least zero digits somewhere, so should match any string whatsoever, while the second will match any string (including the empty string) that contains no non-digits.)

    You know, the documentation for Java methods is available online.

    String.matches(), Pattern.matches(), and Matcher.matches() all behave the same way and attempt to match the entire input sequence against the regular expression. So yes, depending on what flags you have set in your regular expression, ^ and $ won't do anything because they're already implicitly there.

    The method you're looking for is find()...

    ...which is what I end up telling everyone who thinks that Java's easily-accessible regex method works the same way as most other languages' without bothering to look at the documentation.

  • $person_name (unregistered)

    Yeah, the method has a bit of a butter face, but I'd touch it.

  • Latin cod3rz (unregistered) in reply to less-than-less-than-filthy
    less-than-less-than-filthy:
    Yawn. If this is an example of filthy and monstrous to you, I think you better get your job back at reputable $company_name and don't travel far from home ever again.
    Agreed, not monstrous, and not so filthy
  • (cs)

    So TRWTF is a language which requires you to write 8 lines of boiler-plate just to read the entirety of an input stream (be it network, file, process IO, etc)

     InputStream is = Networking.getStreamFromURL(processRequest);
 StringBuffer buffer = new StringBuffer();

    Reader in = new BufferedReader(new InputStreamReader(is));
int ch;
while ((ch = in.read()) > -1) {
buffer.append((char)ch);
}
in.close();
String result = buffer.toString();

    Just give me the string and be done with it: Reader reader = new ...; String result = reader.readAllString(); (I'm sorry, that's too high-level for our high-level IO library :P ). You'd think that at least you could hook up the reader to the writer and say go and it would take care of the direct IO under the covers (looks like java.nio does this, but it's still more convoluted than it needs to be)

  • (cs) in reply to blueg3
    blueg3:
    Steve The Cynic:
    So on Android-Java "[0-9]*" and "^[0-9]*$" are effectively the same thing?

    (Hint: they shouldn't be. The first looks for at least zero digits somewhere, so should match any string whatsoever, while the second will match any string (including the empty string) that contains no non-digits.)

    You know, the documentation for Java methods is available online.

    String.matches(), Pattern.matches(), and Matcher.matches() all behave the same way and attempt to match the entire input sequence against the regular expression. So yes, depending on what flags you have set in your regular expression, ^ and $ won't do anything because they're already implicitly there.

    The method you're looking for is find()...

    ...which is what I end up telling everyone who thinks that Java's easily-accessible regex method works the same way as most other languages' without bothering to look at the documentation.

    That explains why selecting regexes as a solution merely increases the number of problems, that's for sure...

  • mag (unregistered)
    confirmString.equalsIgnoreCase("")

    I like best when he makes sure to check for upper and lower case empty strings

  • radarbob (unregistered) in reply to Latin cod3rz

    Well, uh, I'm going to have to disagree with you there...

    1. We have no empirical "monstrous" or "filthy" standards
    2. Immunity informs judgement
    3. Language Law is not the only criteria.
    4. It's almost never just one thing.

    Here's some of the things that should get this code a firm rejection.

    1. method name "onClick"
    2. method parameter "View v". Might as well just pass in "this"!
    3. equalsIgnoreCase("") really is stupid, per earlier post.
    4. Magic numbers for error conditions. Lost opportunity for some 'code as documentation' and enumerations as type safety, so to speak.
    5. An if-else if with both branches returning the same value.
    6. Extensive checking for explicit conditions then telling the user "... does not seem to be valid"
    7. Bone-headed exception handing, as noted in earlier post. 7a. Beyond undesirable coupling with this exception handing, no attempt to capture the plethora of parameters in this munge of mental mush of a method.
    8. A virtual rape of the single responsibility principle.
    9. Even as is, the code could be perhaps 3 sub-method calls - assuming we can come up with better names than "onClick1".
    10. Not checking for the simplest, most obvious things first - a-la "confirm" not matching - per earlier post.
    11. Burying a mid-method ejection - this.finish(). Guaranteed maintenance headache especially in consideration of observation 8. the try block should end after in.close().
  • Jesper (unregistered)

    Maynard is writing an Android application and he used a Visual Studio plug-in to submit this to TDWTF?

    Is Maynard using Visual Studio to create an Android application?

    WTF.

  • (cs) in reply to airdrik
    airdrik:
    Just give me the string and be done with it: Reader reader = new ...; String result = reader.readAllString(); (I'm sorry, that's too high-level for our high-level IO library :P ). You'd think that at least you could hook up the reader to the writer and say go and it would take care of the direct IO under the covers (looks like java.nio does this, but it's still more convoluted than it needs to be)
    NIO is definitely TRWTF. Particularly frustrating is little things like not being able to use it with subprocesses (i.e., pipelines), though the amount of boilerplate needed is a close-run second. It's also not like the majority of the Java community even realizes there's a problem either: they seem to like the frustration of having to write lots of threaded code to do trivial stuff.
  • Some Damn Yank (unregistered) in reply to ldam
    ldam:
    I always wondered about how to type those uppercase digits...
    With the <SHIFT> key, silly! Uppercase '8' is '*', etc.
  • (cs) in reply to Jesper
    Jesper:
    Maynard is writing an Android application and he used a Visual Studio plug-in to submit this to TDWTF?

    Is Maynard using Visual Studio to create an Android application?

    WTF.

    He's probably using one of the eclipse plug-ins that use the same API. TDWTF Article with links in the featured comments.

  • (cs)

    TRWTF is VB!

    Wait, what language is this again?

  • (cs)
    I think my favorite part is when the 'password' and "confirm' are each checked against a regex, and only then does it check if they are the same string.
    Even better than that: it's not even the right regex, so they have to do an additional length() check.
  • Fred Flintstone (unregistered) in reply to radarbob
    radarbob:
    Well, uh, I'm going to have to disagree with you there...
    1. We have no empirical "monstrous" or "filthy" standards
    2. Immunity informs judgement
    3. Language Law is not the only criteria.
    4. It's almost never just one thing.

    Here's some of the things that should get this code a firm rejection.

    1. method name "onClick"
    2. method parameter "View v". Might as well just pass in "this"!
    3. equalsIgnoreCase("") really is stupid, per earlier post.
    4. Magic numbers for error conditions. Lost opportunity for some 'code as documentation' and enumerations as type safety, so to speak.
    5. An if-else if with both branches returning the same value.
    6. Extensive checking for explicit conditions then telling the user "... does not seem to be valid"
    7. Bone-headed exception handing, as noted in earlier post. 7a. Beyond undesirable coupling with this exception handing, no attempt to capture the plethora of parameters in this munge of mental mush of a method.
    8. A virtual rape of the single responsibility principle.
    9. Even as is, the code could be perhaps 3 sub-method calls - assuming we can come up with better names than "onClick1".
    10. Not checking for the simplest, most obvious things first - a-la "confirm" not matching - per earlier post.
    11. Burying a mid-method ejection - this.finish(). Guaranteed maintenance headache especially in consideration of observation 8. the try block should end after in.close().

    I agree. I would put UX as number one reason for rewrite.

  • Aargle Zymurgy (unregistered)

    After a lecture in a C class on using strupr (and the other string functions) I assigned the simple task of reading in a line and making it upper case. One student added a loop to main to walk the string and in the loop was:

    switch (c) { case 'a': case 'A': c = 'A'; break; case 'b': // continue ad nauseum }

    I guess now I know where that student went to work.

  • (cs) in reply to airdrik
    airdrik:
    So TRWTF is a language which requires you to write 8 lines of boiler-plate just to read the entirety of an input stream (be it network, file, process IO, etc) 
     InputStream is = Networking.getStreamFromURL(processRequest);
 StringBuffer buffer = new StringBuffer();

    Reader in = new BufferedReader(new InputStreamReader(is));
int ch;
while ((ch = in.read()) > -1) {
buffer.append((char)ch);
}
in.close();
String result = buffer.toString();

    Just give me the string and be done with it: Reader reader = new ...; String result = reader.readAllString(); (I'm sorry, that's too high-level for our high-level IO library :P ).

    Wow! Coming from a Delphi background, where "LoadFromStream" methods are idiomatic and can be found on pretty much any object that could conceivably make use of them, that's incredibly ugly.

  • Jerry (unregistered) in reply to Drilnoth
    Drilnoth:
    There only needs to be one set of if/then statements...

    Bah! The entire error variable is unnecessary!

    No, you just caught them in the middle of refactoring to MVC. Eventually, the error decision making will be in the Controller while the error message selection will be in the View.

  • TheJonB (unregistered) in reply to taixzo
    taixzo:
    TRWTF is VB!

    Wait, what language is this again?

    TRWTF is Welsh.

  • Yuriy (unregistered)

    Not sure how this made thedailywtf. This is a typical sample of the majority of code out there. Sad but true.

  • (cs) 
    secretafld.getEditableText().toString()

    Is it unnecessary, or is it Java?

  • JRaymond (unregistered) in reply to radarbob

    This is android... a lot of your 'grievances' are API code.

    1. onClick is the single method of an object that implements the 'OnClickListener' interface. As it's an interface, they can't well change the method signature.
    2. This is a listener, often an anonymous inner class attached to an object. 'View v' is boilerplate, generated code, and true, as multiple views could be attached to this listener.
    3. This is clearly a form submission... how else would one delegate this responsibility? they might have passed things as strings to a separate save method, but then they wouldn't be able to manage the error condition as easily... we can't pass verdict on this without seeing more of the code.
    4. In android, this call allows the method to complete; it merely sets a flag on the overal lifecycle to close the activity when the current run loop finishes.

    Yes, it's a little ugly, but you're making assumptions about the writer without knowing what the problem they're trying to solve is and taking this code snippet out of context, which is TRWTF...

  • Jay (unregistered)

    Funny that they go out of their way to disallow anything other than letters and digits in passwords. Certainly wouldn't want passwords to be too secure now, would we?

    Hey, that gives me an idea. I think my next app I'll check if the password is the same as the user name, is the string "password" or "password1", is the user's phone number or other data included in the user record, maybe a few other truly lame passwords, and if it's none of these, reject it with an error, "Password is too secure."

  • np (unregistered) in reply to blueg3
    blueg3:
    Steve The Cynic:
    So on Android-Java "[0-9]*" and "^[0-9]*$" are effectively the same thing?

    (Hint: they shouldn't be. The first looks for at least zero digits somewhere, so should match any string whatsoever, while the second will match any string (including the empty string) that contains no non-digits.)

    You know, the documentation for Java methods is available online.

    String.matches(), Pattern.matches(), and Matcher.matches() all behave the same way and attempt to match the entire input sequence against the regular expression. So yes, depending on what flags you have set in your regular expression, ^ and $ won't do anything because they're already implicitly there.

    The method you're looking for is find()...

    ...which is what I end up telling everyone who thinks that Java's easily-accessible regex method works the same way as most other languages' without bothering to look at the documentation.

    I was interviewing someone recently and they were using Java to write the functions (I don't have a preference which language they use as long as it is a sane language, e.g. no brainfck). Anyway, he was writing a regex and using .matches(). So I asked a similar question (he had ".(something).", and mentioned that it matches on the whole string, so the . part would be needed). I didn't question it as python has re.search and re.match, the former being the find() and latter being matches()

  • (cs) in reply to minitech
    minitech:
    secretafld.getEditableText().toString()

    Is it unnecessary, or is it Java?

    [image]

  • Joe (unregistered)
    TheArticle:
    if (result.equalsIgnoreCase("1"))

    OMG, the barbarians from ! have invaded my codebase.

    But at least I'm earning my double miles

    --Joe

  • Jack (unregistered) in reply to np
    np:
    I was interviewing someone recently and they were using Java to write the functions (I don't have a preference which language they use as long as it is a sane language, e.g. no brainf*ck). Anyway, he was writing a regex and using .matches(). So I asked a similar question (he had ".*(something).*", and mentioned that it matches on the whole string, so the .* part would be needed). I didn't question it as python has re.search and re.match, the former being the find() and latter being matches()
    Python's re.match does not have to match the whole string, it just has to match at the beginning of the string. So 'myregex' is like '^myregex', not like '^myregex$'.

    But anyway, even given this quirk of String.matches(), I don't think the code does what is intended, because it allows the both the username and password to be empty strings.

  • Jack (unregistered) in reply to Jack
    Jack:
    np:
    I was interviewing someone recently and they were using Java to write the functions (I don't have a preference which language they use as long as it is a sane language, e.g. no brainf*ck). Anyway, he was writing a regex and using .matches(). So I asked a similar question (he had ".*(something).*", and mentioned that it matches on the whole string, so the .* part would be needed). I didn't question it as python has re.search and re.match, the former being the find() and latter being matches()
    Python's re.match does not have to match the whole string, it just has to match at the beginning of the string. So 'myregex' is like '^myregex', not like '^myregex$'.

    But anyway, even given this quirk of String.matches(), I don't think the code does what is intended, because it allows the both the username and password to be empty strings.

    Correction: I see where it prevents empty strings now. Still kind of weird. Like someone else said, why don't they check the easy things first? (Like checking the length of the password before checking what's in it.)

  • that guy (unregistered) in reply to Jack

    I wouldn't call this GOOD code; it could certainly be improved. But it appears to work and mostly do what the author intended. Sure, it could be slightly more efficient (both in implementation and execution) but really... not a WTF.

  • CodeMonkey (unregistered) in reply to Jack
    Jack:

    Correction: I see where it prevents empty strings now. Still kind of weird. Like someone else said, why don't they check the easy things first? (Like checking the length of the password before checking what's in it.)

    Because then the error numbers would have been in the wrong order. Duh.

  • big picture thinker (unregistered) in reply to Tractor
    String processRequest = String.format(ServerCommands.ADD_USER, URLEncoder.encode(userString), URLEncoder.encode(emailString), URLEncoder.encode(secretqString), URLEncoder.encode(secretaString), StaticUtils.md5(passString));

    So all you need to do is send your own request to the server to add a new user account.

  • ironic (unregistered) in reply to Uncle Code Monkey
    Uncle Code Monkey:
    I agree with others commenting, this is a weak WTF. Could it stand to be improved? Certainly. WTF-worthy? imo, no.

    That's what I thought, too! Where's the XML? Wooden Table anyone?

  • nomad (unregistered) in reply to big picture thinker

    Just like any other registration form in the web... What do you think happens when you sign up for some other account in the internet? There's a request sent to the server...

    And if they're using HTTPS, at least the password is transmitted securely, otherwise that would be a much bigger WTF.

Leave a comment on “Less-than Reputable”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article