Comment On convertSingleQuoteAndDoubleQuoteAsciiToCharacters

Now that's just terrible.

oneGottaLoveReallyLongFunctionNamesBecauseTheyAreSoDescriptive()

Shouldn't that method be named like this:

convertSingleQuoteAndDoubleQuoteUnicodeToAscii

?!?

(gotta do it right if at all)

You gotta love how the only two comments in the function are wrong too. &#39 != double quote.

Form and function are completely mistaken in this one.

ThisIsTheNewFunctionToConvertSingleQuoteAsciiToCharactersActuallyNowItAlsoConvertsDoubleQuoteAsciiToCharacters

Dirk:

oneGottaLoveReallyLongFunctionNamesBecauseTheyAreSoDescriptive()

Actually, the teachers I had in computer science all liked long function names; in at least one assignment, I made a really convoluted function name, like createLabelToPlaceAtTheTopOfTheUserInterface(), just to get them to tell me that I needed to remove some words in that.

Back on topic, though, isn't that an HTML Entity to ASCII converter, and not ASCII to character?

convertSingleQuoteAndDoubleQuoteHTMLEntityToASCIICharacters() would be a more fitting name for the function... ;)

This method should really be called convertFirstSingleQuoteAndDoubleQuoteAsciiToCharactersAndGoIntoAnInfiniteLoopIfThereAreMore.

Looce:

convertSingleQuoteAndDoubleQuoteHTMLEntityToASCIICharacters() would be a more fitting name for the function... ;)

Or findMoreThanOneOfTheSameQuoteCharactersByNotReturningAnyMore().

As a very broad and general rule, once I've descriptively named a method something like that, it tells me I should rethink the method. After all, if it takes that long to describe it, it's possible that it needs to be refactored.

Not a hard and fast rule but it at least gets me thinking.

Sometimes I think some programmers try to rewrite some useful code at locations where it would be extremely useless, just to show they are capable at creating garbage that looks nice.

I think I will have to get some more dried frogpills.

I especially like:

tmpIndex = str.indexOf("'");  // double quote

and

tmpIndex = tmpName.indexOf("""); // single quote

There's nothing like a good old misleading comment to set you up for the rest of the code...

I must admit it took me a while to notice said loop. :-\.

ok:

I must admit it took me a while to notice said loop. :-\.

You're not the only one :( I'd like to blame my lack of experience with Javascript, but I don't think that would really do anything to mitigate my shame.

Kuli:

Looce:

convertSingleQuoteAndDoubleQuoteHTMLEntityToASCIICharacters() would be a more fitting name for the function... ;)

Or findMoreThanOneOfTheSameQuoteCharactersByNotReturningAnyMore().

Let's just cut to the chase and call it thisIsAStupidFunctionWhichShouldNeverBeUsedForAnyPurposeUnderAnyCircumstances(youHaveBeenWarned)

C Gomez:

As a very broad and general rule, once I've descriptively named a method something like that, it tells me I should rethink the method. After all, if it takes that long to describe it, it's possible that it needs to be refactored.

Not a hard and fast rule but it at least gets me thinking.

How true, how true, particularly when the thinking get's you to look in the class library and notice String.Replace(). Be careful, this usually coincides with possibly unexpected performance gains as well.

Mickey:

Now that's just terrible.

no kidding.

To the author of the original code:
Keep your hands in your pockets next time you see a computer, trust me.

'How did their data get “'” in the first place?'

TinyMCE does this in certain circumstances. At least, I find myself having to clean them up, for reasons I am not clear on. It would certainly explain why there was a need to process them in javascript.

Has anyone noticed how many of these involve string processing? I suppose string processing is kind of annoying sometimes, but why does it produce so many glorious WTFs?

The infinite loop is teh awesome. DoS, anybody?

Yes, but it's Self Documenting©

anne:

Has anyone noticed how many of these involve string processing? I suppose string processing is kind of annoying sometimes, but why does it produce so many glorious WTFs?

I've seen countless coders really infatuated with strings. Doing things like <number>.toString().trim(), which would be toString()'ed AGAIN some lines later, then converted back to numeric. String being like a panacea: not working? .toString() it!

Being so lovely and overused, it's no wonder why they end up WTF'ed...

All things considered, it's probably best that the guy who wrote this doesn't know about regexes.

C Gomez:

As a very broad and general rule, once I've descriptively named a method something like that, it tells me I should rethink the method. After all, if it takes that long to describe it, it's possible that it needs to be refactored.

Not a hard and fast rule but it at least gets me thinking.

For real, but you also gotta make sure you're documenting what the method accomplishes, not how it works. In this case, a better name might be "UnescapeQuotes"

Although a WTF by any other name...

It should be named

replaceCharacterEntities(string)

Perhaps I'm being stupid, but what's wrong with this code, other than being redundant? I don't see why it would infinite loop, possibly because I've never tried to manipulate strings in ecmascript.

TheRider:

Shouldn't that method be named like this:

convertSingleQuoteAndDoubleQuoteUnicodeToAscii

No, it shouldn't.

Let's all, please, divorce ourselves of the idea that Unicode is a character set, or character representation in any way, shape or form. It is not. Unicode is an attempt at a canonical set of all written glyphs, no matter what language or languages they occur in, with a unique value assigned to each. A character set is a specification of binary representations of a set of glyphs. UTF-X are also *NOT UNICODE*. They are character sets which provide specifications for the binary representations of glyphs contained in the Unicode canon.

What this guy was trying to do was convert the *HTML representation* of the Unicode value of a given glyph to an *ASCII character set* representation of the same glyph.

Why is Unicode so hard?

Marcin:

Perhaps I'm being stupid, but what's wrong with this code, other than being redundant? I don't see why it would infinite loop, possibly because I've never tried to manipulate strings in ecmascript.

It took me a shamefully long time to figure it out as well. It's because in his first loop if a 2nd entity is found it will use the original string to replace it. So basically it will flip-flop between the two &#39; strings converting one to a ' and having the other one reverted back to a &#39;

Marcin:

Perhaps I'm being stupid, but what's wrong with this code, other than being redundant? I don't see why it would infinite loop, possibly because I've never tried to manipulate strings in ecmascript.

Well... take a look at the first loop, and check what happens when a characted index from ONE (mutable) string is used to extract text from ANOTHER (constant) string... That is the problem with tmpIndex, tmpName and str.

function names are apologies?

H|B:

Marcin:

Perhaps I'm being stupid, but what's wrong with this code, other than being redundant? I don't see why it would infinite loop, possibly because I've never tried to manipulate strings in ecmascript.

Well... take a look at the first loop, and check what happens when a characted index from ONE (mutable) string is used to extract text from ANOTHER (constant) string... That is the problem with tmpIndex, tmpName and str.

Oh good point. I guess the real WTF is that they didn't use functional programming.

Marcin:

Perhaps I'm being stupid, but what's wrong with this code, other than being redundant? I don't see why it would infinite loop, possibly because I've never tried to manipulate strings in ecmascript.

Inside the while loop it keeps working with the str variable instead of the tmpName variable, so on the second pass it reintroduces the first &#39; into tmpName, then on the third pass reintroduces the second one, on the fourth pass the first one again, etc ad infinitum

Marcin:

Perhaps I'm being stupid, but what's wrong with this code, other than being redundant? I don't see why it would infinite loop, possibly because I've never tried to manipulate strings in ecmascript.

It's easy to overlook, because we tend to see what we want to see. I had to look a couple of times to see it, too, and I only did that because I knew (thanks to comments) that there was an infinite loop.

Inside the loop (so on all iterations other than the first), the code keeps scanning the original, unmodified string to see if it contains the target sequence. Since it scans the unmodified string, it will always find it.

When we see what appears to be an iterative scan-and-replace pattern, we assume that the author avoided this bug, either by starting each scan from after the previous hit, or by recursively rescanning the modified input. (The latter is obviously less efficient - O(n**2) in the worst case rather than O(n) - but elegant when implemented in functional style, which may make it preferable in some situations if performance isn't an issue.)

--
Michael Wojcik

InPvpAShadowPriestTheFacesWillMelt()

Why does the coder insist reproducing Javascript’s String.Replace() function?

Duh, you don't get LOC bonuses by using libraries! =)

As the code is written, it'll always return the input string. Since tmpIndex = -1 at the top, while(tmpIndex > -1) will never run. Of course, that's probably just a transcription error.

Arg, I'm an idiot. Or really tired. Or both (probably this one).

benk:

As the code is written, it'll always return the input string. Since tmpIndex = -1 at the top, while(tmpIndex > -1) will never run. Of course, that's probably just a transcription error.

eh, tmpIndex is assigned a value IF it find the character in the string...

tmpIndex = str.indexOf("&#39;");

I found something like this once (but with variables - that were set far in advance of the call - instead of literals). The only thing I can figure is that it used to do the replacements, and at some point, they became unnecessary. The subsequent coder didn't realize they were just undoing a preious replace, and the whole thing could have been eliminated, so they just tacked on additional calls to replace to "fix" the broken string.

String wtf = someString.replace("A","B").replace("C","D").replace("B","A").replace("D","C");

JF:

benk:

As the code is written, it'll always return the input string. Since tmpIndex = -1 at the top, while(tmpIndex > -1) will never run. Of course, that's probably just a transcription error.

eh, tmpIndex is assigned a value IF it find the character in the string...

tmpIndex = str.indexOf("&#39;");

Sorry didn't see your 2nd post :) guess I'm tired as well.

Just let those punks at Apache do all the hard work for you.

StringEscapeUtils

anne:

Has anyone noticed how many of these involve string processing? I suppose string processing is kind of annoying sometimes, but why does it produce so many glorious WTFs?

The infinite loop is teh awesome. DoS, anybody?

No idea, but you're right, it crops up a lot; or else we see my own personal favourite technique - date processing by means of toString() and string slicing. Yuk.

Oddly, shortly after I discovered automated unit testing, I tried it on this kind of isolated string processing function, and found that it is is ideally suited to rapidly and completely testing this kind of function. I guess you need to avoid unit testing and refactoring altogether in order to to make this kind of infinite-loop wtf.

foxyshadis:

Just let those punks at Apache do all the hard work for you.

StringEscapeUtils

And how do you call a java class from JavaScript? Ah, sure, just add a web service! That's so enterprisey...

Another WTF:
tmpIndex will be the offset of &#39 in tmpName which will replace the wrong characters in str the second time through the loop since tmpName is 4 characters shorter than str. Depending upon where the two occurrences of &#39 are would either cause an infinite loop or return with some funky results.

Consider the string: &#39;Hi&#39;
Expected result: 'Hi'
Actual result: &#3'#39;

Been there done that don't care any more:

I found something like this once (but with variables - that were set far in advance of the call - instead of literals). The only thing I can figure is that it used to do the replacements, and at some point, they became unnecessary. The subsequent coder didn't realize they were just undoing a preious replace, and the whole thing could have been eliminated, so they just tacked on additional calls to replace to "fix" the broken string.

String wtf = someString.replace("A","B").replace("C","D").replace("B","A").replace("D","C");

Yeah ... dont maintain any of my code thx. Complete noop innit....

>>> var a = "BBAA"; var b = "AABB";

>>> a.replace("A","B").replace("C","D").replace("B","A").replace("D","C")

"ABBA"

>>> b.replace("A","B").replace("C","D").replace("B","A").replace("D","C")

"AABB"

Alex Papadimoulis:

If you pass ")&#39;Malley&#39;'s Irish Pub" it will … actually, never return.

Hey! Who are you to decide the halting problem? :-)

Marcin:

Perhaps I'm being stupid, but what's wrong with this code, other than being redundant? I don't see why it would infinite loop, possibly because I've never tried to manipulate strings in ecmascript.

The second and all later indices are obtained from tmpName, but the substrings used to reconstruct tmpName are taken from str, which is never modified.

Thus, if str is &#39;foo&#39;, tmpName will alternate between 'foo&#39; and &#39;foo', ad infinitum.

Even if this was fixed, the function would have quadratic worst-time performance, but hey, at least that means runtime is finite.

There are more gems in this function.
- Pointless use of temporary variables tmpName and tmpName2
- Variables named tmpName and tmpName2 that do not necessarily hold a name
- The ifs don't do anything. Ever. The only reason why tmpName.length would be less than 1 is that str is empty. But then tmpName, which is empty, is overwritten with str, which is empty.
- str.replace would have worked fine
- Why write a function that can only replace &#34; and &#39; instead of all HTML rsp. XML entities?

I just didn't expect it to find the replaced "'" character. Too much discipline from Perl regular expressions in my skull to realize how plain silly Javascript is.

Mystified:

What this guy was trying to do was convert the *HTML representation* of the Unicode value of a given glyph to an *ASCII character set* representation of the same glyph.

Nonsense! What he was trying to do is converting the HTML entities for single and double quote to ordinary characters. What do ' and " in JavaScript have to do with ASCII?

Mystified:

Why is Unicode so hard?

Good question indeed.

MichaelWojcik:

Since it scans the unmodified string, it will always find it.

No, it doesn't.

me:

And how do you call a java class from JavaScript? Ah, sure, just add a web service! That's so enterprisey...

Just don't forget to XML escape your stuff before sending it to the web service. :-)

Wow, that's a weird piece of code.

I've done some stuff like this myself, but never to this extent. (And, in case anyone is wondering: the legitimate reason to do stuff like this is to make your Javascript run in really old browsers. In this case, it's pointless, because String.replace dates to Netscape 4 and IE 4; nobody's going to expect anything older than that to work anyway these days. If that was the goal, and this was not mere cluelessness, they still made an error: there is some browser version -- I forget which, but it might have been a version of IE for Mac -- you can't assume arguments are proper String objects to begin with and have to explicitly use "str = new String( str )" at the top of your code to make sure the browser knows what you mean.)

drStranglove()||doubleQuoteHowICameToStopWorringCommaAndLoveTheBombPeriodEndQuote()

since this is javascript, you'd only be DoS'ing yourself...