The Daily WTF: Curious Perversions in Information Technology

2010-01-07 Reply Admin

Java Refugee:
The StringBuffer use indicates this predates jre1.5, and the compiler optimization that came with it. Using a StringBuffer was the preferred, recommended solution over direct String concatenation.
See http://java.sun.com/developer/JDCTechTips/2002/tt0305.html

Or the first edition of "Effective Java" or really anything that is older than 1.5 which all pretty much agree on this topic.

Of course, the code then goes on to use string concatenation anyways, and the method name is still silly.

Gah. Wrong. This stuff isn't that hard, people, which is why I can't fathom how so many of you can be so very wrong about it.

StringBuffer (and now StringBuilder) is the only sane way to do string concatenation in Java. So the question isn't "should you use StringBuilder" -- the answer to that is always "yes", because you are going to whether you like it or not. The question is "should you use an explicit StringBuilder as opposed to letting the compiler make one for you", and the answer to that is simple and obvious: only if it makes sense to reuse it.

In other words, String foo = ""; for (int i = 0; i < 100000; i++) foo += "foo"; is stupid, because you are letting the compiler create 100,000 different StringBuilders for you. It makes a lot more sense to create one and append to it a hundred thousand times. For big strings with tons of concatenations, the performance difference is astronomical. But again, it's not "using StringBuilder" versus "not using StringBuilder", it's "using one StringBuilder" versus "letting the compiler create a hundred thousand of them for you".

For the WTF function, it makes no practical difference whether he creates his own StringBuilder or lets the compiler do it for him, because there's only one concatenation sequence and therefore no value to manually creating the StringBuilder. That, of course, does not make this the right way to do things -- much better to manually create the StringBuilder outside of this function, so it can be used for the whole concatenation and not just this tiny piece of it. And obviously there is other stupidity here as well.

2010-01-07 Reply Admin

RandomUser423662:
It would be nice to have a clean way to deal with the line-terminator characters, and doubling-double-quotes seems a bit hack-y (but that's how it evolved), but otherwise I find myself agreeing with "VB Programmer". For-why do people seem to think VB(.NET) "vitally needs" backslashes for strings?

It does not "vitally need" them, but try writing a parser that can read everything that Excel writes when "save as CSV". Be sure to test

Strings without special characters that are written unquoted
Strings with commas in it, which are written quoted
Strings with double-quotes in them, which are written quoted and the double-quotes are doubled.
Strings with CRLF in it

Compare this with a format where a backslash escapes the next char. You only have to remember the last character in the parser, while in the CSV-parser you have to remember multiple modes.

The CSV parser is a lot more complicated and this is why 99% of all CSV parsers([Citation needed]) cannot parse CSV files.

And it explains why todays WTF is a WTF:

String result = insertComma("String1") + "," +
insertComma("String2, that contains a double-quote\", actually two\"");

CAPTCHA: illum (partially illuminated now?)

2010-01-07 Reply Admin

Design Pattern:
... but try writing a parser that can read everything that Excel writes when "save as CSV".

Ah, yes. I will freely admit there are annoying syntaxes out there that would be much simplified by addition of an escape character akin to C's backslash.

I was merely responding to the recurrent abuse VB gets for not supporting such an escape character. With the specific exceptions I noted previously, it simply has no use for one.

(The other part of the response, that I left out because it has been said before, is that VB doubles the string delimiter instead of backslashing it because of precedent from preceding BASICs, and some other languages of that time.)

2010-01-07 Reply Admin

RandomUser423662:
For-why do people seem to think VB(.NET) "vitally needs" backslashes for strings?

This argument about string substition is far older than B,VB,(.NET), C or Pascal. It was the "One True Style" question of Fortran and machine code. It is the 50s/60s equivilant to the question "Should temp variables be declared inline?"

Watson · 2010-01-08 Reply Admin

RandomUser423662:
Design Pattern:
... but try writing a parser that can read everything that Excel writes when "save as CSV".
Ah, yes. I will freely admit there are annoying syntaxes out there that would be much simplified by addition of an escape character akin to C's backslash.

So combining the arguments of both you and VB Programmer:

it would be nice to have them; not having them leads to hackiness whenever string literals aren't well-behaved; the only reason VB doesn't have them is historical; the only thing to be said in favour of their absence is that VB wasn't designed with succinctness in mind.

Apparently it doesn't enable anything that can't be done in the same way in C except with even less syntax (i.e., one escape character for all purposes instead of different escape characters for escaping different characters, and char[] z = "foo" vbcrlf "bar"; would be legitimate if you did something like #define vbcrlf "\r\n" beforehand - note the lack of an '&' operator).

Thank you for your responses and stirring case for the defence. I'd drifted away from BASIC decades ago, and wondered if it would be worth brushing up on what it had become - most of my acquaintance with it came from decompiling CLR as both VB.NET and C# and comparing. So some time back I asked if there were any reasons why I ought to learn VB.NET, but nobody replied.

Watson · 2010-01-08 Reply Admin

Ethan:
much better to manually create the StringBuilder outside of this function, so it can be used for the *whole concatenation* and not just this tiny piece of it. And obviously there is other stupidity here as well.

I'm willing to notionally bet that this is exactly what is happening: that the string just created in this method will be appended to a StringBuffer in the calling method, which finishes by returning the realised string to it's caller which appends it to another StringBuffer....

I've seen that idiom more than once before today.

hikari · 2010-01-08 Reply Admin

Anon:
smbarbour:
On the other hand, the code above is C# and not VB (hint: VB doesn't use semi-colons and curly braces).

Try again, .NET doesn't have a StringBuffer, it has a StringBuilder. You must be a VB 6 programmer or you'd know that. The camel casing suggests Java.

Or they've just never used StringBuilder. I'm not sure which is more scary.

Although, afaik, string concatenation is better than StringBuilder for trivial amounts of concatenation. If it's less than 10, I tend to stick with concatenation, unless you're doing it in a loop, then StringBuilder is the way to go.

String.Format() uses a StringBuilder internally, iirc.

2010-01-08 Reply Admin

I'm tempted to say the guy who wrote this was Hispanic and confused "comillas" (quotes) with "comas" (commas).

2010-01-08 Reply Admin

Watson:
So combining the arguments of both you and VB Programmer:
it would be nice to have them; not having them leads to hackiness whenever string literals aren't well-behaved; the only reason VB doesn't have them is historical; the only thing to be said in favour of their absence is that VB wasn't designed with succinctness in mind.

Apparently it doesn't enable anything that can't be done in the same way in C except with even less syntax (i.e., one escape character for all purposes instead of different escape characters for escaping different characters, and char[] z = "foo" vbcrlf "bar"; would be legitimate if you did something like #define vbcrlf "\r\n" beforehand - note the lack of an '&' operator).

A fairly reasonable interpretation.

The main complication VB strings run into is line-terminator characters. All other (non-delimiting) characters can be entered directly. If not for the unfortunate risks involved in making such a change, my personal recommendation would be to allow strings to include line-terminator characters.

The specification is otherwise quite clear, that strings are delimited by double-quote characters, and the only gains (syntactically) by disallowing the others are avoiding the "weirdness" of strings visually continuing on the next line, and avoiding the coincident "breaking" of indentation. (There is the potential added complexity to the parser, but I'm fairly sure VB already requires a context-sensitive grammar.)

(Now that I think about it, there may be precedent for this. Anyone remember for sure whether Commodore or Apple BASIC allowed line-end characters embedded in strings?)

I find it reasonable to say that succinctness wasn't a design goal (just consider how "wordy" VB is, compared to several other languages); but more importantly, its BASIC parentage (emphasizing simplicity, for "beginners" sake) likely had little need for embedding line-ends in strings. Most of the commonly-used output statements (PRINT, etc.) appended a line-end anyway, so most BASIC programs just output one line at a time instead of trying to build up one string with all the lines in it.

2010-01-12 Reply Admin

Check out the semantic of the +-operator for strings and you will see, that it results in an extra copy of the whole string. I think you do now understand the point.

Insert Comma?

Leave a comment on “Insert Comma?”