• Electrawn (unregistered)

    I am guessing this is possibly used in a password enforcement security rule? My best guess as to why you would compare backwards.

    Or for Date/Time rendering that are not in the form of YYYYMMDD.

    Captcha: quake - head shot!

  • Erik N (unregistered) in reply to bstorer
    bstorer:
    Erik N:
    It's good they did what they did because.......

    A.trim(); return A.endsWith(B.substring(B.length - 11));

    Is sooooo confusing.

    Ah, but you also need to make sure they aren't equal, too.

    Good point and I knew that. I was just replacing the very inefficient WTF code.

    <rant style="grumpy old developer">I mean what if I gave you two strings that happen to be 1MB in size? Yes a processor can do that pretty quickly but you're wasting memory and cpu cycles for pointless work. I've been writing code for 23 years now (started at 12) and I think developers just continue to get worse. </rant>

  • 18Rabbit (unregistered)

    ("ThisContainsOneTwoThree", "OneTwoThree") returns true. The second string has to be 11 characters long (a phone number perhaps?). I'm not sure what the difference in backwards is supposed to make. I'd rewrite it as:

    public boolean containsNotEqual(String from, String to) {
    if ((from.equals(to) || (!from.contains(to)))) {
        return false;
    } else {
        return from.lastIndexOf(to) == (from.length() - 11);
    }
}

    This also eliminates the IndexOutOfBoundsException.

  • BlueEagle (unregistered) in reply to KattMan
    Licky Lindsay:
    Awww... this was coded on Valentine's day. How sweet.

    Ohh.. this was coded on Valentine's day. How sad.

  • Andrew (unregistered) in reply to Loren Pechtel
    Loren Pechtel:
    I also at first thought of backwards languages & UTF characters but that's not what's going on here. It's simply an attempt to see if the last 11 characters of the first string match the whole second string.

    The Java language uses fixed-width Unicode characters. It allows conversions using FileReader/FileWriter and String objects. However, every in-memory Char is Unicode (UCS2 or 16-bit as of Java 1.4).

    So, one never cares about the character set in a java.lang.String object. The exception is JNI native code, which must marshall C/C++ strings to Unicode (See the Java Native Interface).

  • (cs) in reply to Mith
    Mith:
    I'd go further and spell "Know" correctly

    Nah, the function name is much more appropriate without the 'K'. You know, just to make sure the initial warning in the function name sinks in when you run across it somewhere else in the code.

  • (cs) in reply to Mr Fred
    Mr Fred:
    Valdis Kletnieks:
    I'm surprised not a single person has noted that in multinational companies, there *might* just be a need to process BIDI (BidDirectional) langauges, or ones that are read right-to-left, so comparing the *last* 11 characters might actually be The Right Thing To Do.

    That is because the right to left vs left to right is merely the spatial display convention indicating which characters are first vs last. It has nothing to do with the ordinality of the string elements which is present in the string array.

    Sir, I believe you might be overestimating the programmers we are dealing with here. I really wouldn't put it past someone to write a BIDI system where the strings are reversed in their memory representation. It still, in no way, qualifies as "The Right Thing To Do(tm)". This code never qualifies for any award other than a frontpage post to this site.

  • sf (unregistered) in reply to Blort
    Blort:
    Vic:
    You call a code written in 2002 old? How old are you?

    It should be impossible to call any Java "old". Some C might be old. A fair amount of FORTRAN is old. Almost all COBOL is old. Java isn't even middle-aged!

    Perhaps calling 5 year-old code "old" some sort of insight into the mind of the Java developer? "Ohh, that's more than 12 months old and doesn't use the latest java.util.flibFlobStringParserWoble class, I'd better re-write it!"

    You should rewrite. java.util.flibFlobStringParserWoble has already been deprecated.

  • (cs) in reply to punissuer
    punissuer:
    Blort:
    Vic:
    You call a code written in 2002 old? How old are you?

    It should be impossible to call any Java "old". Some C might be old. A fair amount of FORTRAN is old. Almost all COBOL is old. Java isn't even middle-aged!

    Perhaps calling 5 year-old code "old" some sort of insight into the mind of the Java developer? "Ohh, that's more than 12 months old and doesn't use the latest java.util.flibFlobStringParserWoble class, I'd better re-write it!"

    Consider that that whole field of web development is only around 12 years old, and how much Java grew and changed in its first few years. Also, would you use a web browser that was five years old?

    Old is definately a relative term. Maturity is a logarithmic function. Anyone who has a child knows that a newborn is infinately less mature than a three-year-old, which is drastically different than a five-year-old, which is different from a twelve-year-old. I think that same rule applies to technology, including programming languages. There is a point when the aging starts to level out, and like children, is dependent on itself and its creators.

    The vast majority of Java that I've had to support that is 5+ years old was either written by people who have never programmed before (thank you dot com era), or programmers who used other older non object-oriented languages. The old COBOL programmers, who may have been excellent programmers, didn't always adapt to Java's OO methodology, and thus wrote code that was not easy to maintain and thus needing of rewriting after only a few short years of service. (Please don't flame me, accusing me of COBOL biggetry. I am just stating that COBOL programmers and JAVA programmers tend to see things very differently) As for the people who had never programmed before, that code was typically impossible to understand let alone maintain.

    So, with the mix of unaccustomed developers and the infancy of the language, I believe it is perfectly legitimate to consider 5+ year-old Java code old, with "old" being synonomous with "outdated".

  • al (unregistered)

    I love variables with articles in their names. Not just any StringToCompareTo, this is THEStringToCompareTo. I should stop using i in for loops in favor of "anInteger"

  • Anon (unregistered) in reply to al
    al:
    I love variables with articles in their names. Not just any StringToCompareTo, this is THEStringToCompareTo. I should stop using i in for loops in favor of "anInteger"
    I've considered using "iVeGotAutoCompleteHowAboutYou" before, but I've never been that cruel.

    Yet.

  • Blort (unregistered) in reply to dphunct
    dphunct:
    So, with the mix of unaccustomed developers and the infancy of the language, I believe it is perfectly legitimate to consider 5+ year-old Java code old, with "old" being synonomous with "outdated".

    I believe the word you are looking for is "rubbish" or "broken". In your case, you were re-writing young code because it was wrong, broken, or downright unmaintainable: you were not re-writing it because it was merely "old".

    What I've been trying to get at is that re-writing something just because it is "old" and doesn't conform to your latest idea of what's best practice (Read: Doesn't use the latest whizz-bang framework features), even if the code you are re-writing works, is a really bad idea. Yet it seems a lot of developers spend quite a bit of time doing just that. I wonder how many developer man hours are wasted re-factoring perfectly good code because someone didn't like the look of it?

  • clintp (unregistered) in reply to dphunct

    Old code for me means more than 20 or 30 years old. For me old means:

    ... the company that developed the code originally been bought, gone out of business, been resurrected, and declared Chapter 7 and 11 at various times

    ...and the industry that developed it no longer exists, except as a legacy support

    ...the language is at least 3 ANSI/ECMA revisions behind

    ...the compilers no longer exist for the language you are using

    ...at least some of the developers of the code have retired

    ...and at least is dead, of old age.

    Now that is old code. Java! Pffft!

  • (cs)
    (String theStringToCompareFrom, String theStringToCompareTo)

    It's bad style to end your parameters with a preposition.

  • Ada Lovelace (unregistered)

    The comments here always contains more WTFage than the submission.

    1. Palindromes don't break it. That's just dumb.
    2. Here's what it's doing:

    False If the strings are equal. True if (up to) the last eleven characters of the From string, trimmed of leading or trailing whitespace, match the trimmed To string.

    1. The WTFs in the submission are:

    a) there's no need to reverse the To string. b) There are better ways to accomplish the whole thing.

    1. Probable WTF: As it seems rather unlikely that this function, as written, would be useful, it probably does not do exactly what the author thought it did.
  • Ada Lovelace (unregistered) in reply to Ada Lovelace

    "The comments here always contains more WTFage than the submission. "

    Including my own, of course. No one is immune to the powers of this site.

    Ignore 3a.

  • Harrow (unregistered) in reply to Mr. Proper
    Mr. Proper:
    (String theStringToCompareFrom, String theStringToCompareTo)

    It's bad style to end your parameters with a preposition.

    Definitely. I always use eg.

    String theStringToCompareFromDummy String theStringToCompareToYouIdiot

    -Harrow.

  • (cs) in reply to dphunct
    dphunct:
    The old COBOL programmers, who may have been excellent programmers, didn't always adapt to Java's OO methodology, and thus wrote code that was not easy to maintain and thus needing of rewriting after only a few short years of service. (Please don't flame me, accusing me of COBOL biggetry. I am just stating that COBOL programmers and JAVA programmers tend to see things very differently)
    The IT manager at my previous job had been promoted from COBOL programmer. They had a "mainframe" with several COBOL applications on it; some of my first assignments there involved converting the COBOL apps to run on Windows with VB. When .Net was in beta and everyone was talking about using any language for coding, I once heard him muse wistfully, "I hope someone comes out with COBOL for .Net. That's a great programming language."

    When you're holding a hammer, everything looks like a nail.

  • Someone (unregistered) in reply to Erik N

    Except for its impact on global warming, that would be equivalent to

    return A.endsWith(B.substring(B.length - 11));

    (Strings are immutable in Java). If you want someString.trim() to have some useful effect, you must assign its return value to something, as in

    A = A.trim();
  • iToad (unregistered) in reply to Phlip
    Phlip:
    So... * Returns false if the strings match exactly (including whitespace) * Returns true if the second string matches the last 11 characters of the first string (ignoring leading/trailing whitespace) * Returns false otherwise. * Throws IndexOutOfBoundsException if the strings don't match exactly and the first string is less than 11 characters long.

    I think that covers it.

    I think that this is an excellent example of the kind of functional description, that should have been contained in the comments at the start of the function.

  • AT (unregistered) in reply to FredSaw

    Looks like his wistful musing came true, more's the pity:

    http://www.netcobol.com/products/windows/netcobol.html

    I would ask "why?", but I don't think I'd like the answer...

  • Stefan W. (unregistered)

    Not too important, but nobody mentioned the twisted parameters in the comment.

    The superLongVariableNames are, of course, a WTF.

    It could have been a comparision of something like phone-number, where "from" might contain an area code 030/789 505 123 compared to 789 505 123 - but it's returning false for exact match.

    Trimming the substring, not substringing the trimmed string, seems to be a hint for a prefix which might or might not be divided by a space.

    Perhaps "Mon 2007/09/25" vs. "2007/09/25"?

    btw.: 14.2.2002 was a thursday.

  • goesuptoeleven (unregistered) in reply to flux
    flux:
    And why are they taking the substring from 0 to 11?

    Obviously so it goes up to 11.

  • (cs) in reply to Vic
    Vic:
    You call a code written in 2002 old? How old are you?

    Maybe it was written in 1902

  • Synonymous Awkward (unregistered) in reply to Phlip
    Phlip:
    So... Christ knows what it was actually intended to do though (actually, maybe he doesn't, I don't remember the part of the bible where he learned how to program in Java).

    Of course not. God uses Lisp.

  • Knitpik (unregistered) in reply to al
    al:
    I love variables with articles in their names. Not just any StringToCompareTo, this is THEStringToCompareTo. I should stop using i in for loops in favor of "anInteger"
    I want to see more database table names using the, an, data, value, stuff, thing, etc. And crazy capitalisation, mis-spelling, and plurals too. Like "theNewDATAValues", "Valuestuff", "THEDATAS", "Myvalues", "athingStatusrecords", "oldParent_varible"...
  • nano (unregistered)

    I'm not 100% on java, but wouldn't 0-11 return 12 characters? Just right for an 8.3 filename..

  • asifyoucare (unregistered) in reply to MET
    MET:
    For me, the real WTF is just another case of people naming functions by how they are implemented rather than what they are for. The last 11 characters may be some domain specific information that may be guaranteed to be present by the time this function is called. For example if it were renamed to orderSpecialFeatureEqual() or whatever the real use was it would be less of a WTF.

    OTOH reversing both the strings is just mental :)

    I think the author is reversing the strings because he wants to find end-point the LAST match (and he hasn't learnt about lastIndexOf). Of course it is dangerous to try reading the mind of an idiot.

  • Jules (unregistered) in reply to nano

    No, the second index is exclusive.

  • (cs) in reply to Synonymous Awkward
    flux:
    And why are they taking the substring from 0 to 11? they might as well call this method method0.

    Or madness0.

    Synonymous Awkward:
    Of course not. God uses Lisp.

    And the Lord could not count grains of sand with a 32-bit word. Who knows where we would go to if Lisp weren’t what he preferred?

  • (cs) in reply to nano
    nano:
    I'm not 100% on java, but wouldn't 0-11 return 12 characters? Just right for an 8.3 filename..

    No. It's a little strange, but the string you get back does not include the character in position 11. I was once advised to think of it like so: the first index is the first character you want, while the second is the first character you don't want. I'm not sure why that decision was made, but we're pretty much stuck with it at this point.

  • Nelle (unregistered) in reply to 18Rabbit
    18Rabbit:
    ("ThisContainsOneTwoThree", "OneTwoThree") returns true. The second string has to be 11 characters long (a phone number perhaps?).

    Good one. Me thinks it is a method to compare a phone number without country and area codes.

  • (cs) in reply to Knitpik
    Knitpik:
    I want to see more database table names using the, an, data, value, stuff, thing, etc.
    I use "thing" all the time. What could be more appropriate for a generic object? 
    [image]
protected string getContainerImagePath(object thing)
{
	string path = string.Empty;
	DataRowView row = (DataRowView) thing;
	(snip) // process the row data
	return path;
}
  • Stefan W. (unregistered) in reply to nano
    nano:
    I'm not 100% on java, but wouldn't 0-11 return 12 characters? Just right for an 8.3 filename..

    Does not make sense: a) It's 11 characters, as mentioned before. b) Stripping off something could be a path, but you weren't forced to use all characters, you could use 6.2 (like foobar.js) and would get parts of the path that way.

  • AdT (unregistered) in reply to Mr. Proper
    Mr. Proper:
    It's bad style to end your parameters with a preposition.

    This is something I absolutely agree with. Don't end your parameter names or sentences with a preposition unless you absolutely have to!

    Captcha: xevious (I had a hard time trying to type this in.)

  • (cs) in reply to AdT
    AdT:
    This is something I absolutely agree with. Don't end your parameter names or sentences with a preposition unless you absolutely have to!

    Captcha: xevious (I had a hard time trying to type this in.)

    Triple prepardy! Caution; once you're in the habit, it's hard to get out of.

  • koni (unregistered) in reply to al
    al:
    I love variables with articles in their names. Not just any StringToCompareTo, this is THEStringToCompareTo. I should stop using i in for loops in favor of "anInteger"

    No, you should use "anIntegerThatIAmUsingAsALoopCounterInThisFunctionWhichMayOrMayNotBeUsedElseware" after all, you don't want ambiguous variable names!

  • andy (unregistered)

    Give the author of that code a break. I myself have written pages of code only to replace them a week later with one line doing exactly the same.

    Still it's a funny piece of code there. hehe

  • writer (unregistered) in reply to koni
    al:
    anIntegerThatIAmUsingAsALoopCounterInThisFunctionWhichMayOrMayNotBeUsedElseware

    Hardware. Software. Elseware.

  • jcc (unregistered) in reply to andy

    ah ha... it was you wasn't it!!!

  • jcc (unregistered) in reply to andy
    andy:
    Give the author of that code a break. I myself have written pages of code only to replace them a week later with one line doing exactly the same.

    Still it's a funny piece of code there. hehe

    ah ha... it was you wasn't it!!!

Leave a comment on “containsNotEqualBackwards”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article