Comment On The Great Code Spawn

I can't work out which is worse...the abuse of string concatenators, or the fact that there are still people out there who write SQL like that.

Still, I've seen worse.

I believe that, when executed, this code can make the universe explode.

Mr B:

I can't work out which is worse...the abuse of string concatenators, or the fact that there are still people out there who write SQL like that.

Still, I've seen worse.

He didn't write the SQL like that. It was the code that wrote it.

comments.append(first).append(post).append(post).append(wtf).append(post).append(troll).append(post).append(wtf).append(self);

That's what happens when one takes "abstract thinking required" in his job a bit too seriously.

Get a ream of Z-fold, run a daisy wheel printer on it and you've got yourself an art installation.

My first thought was "Looks like abstract art to me". And then I started wishing it was in fact abstract.

This has to be the uncontested winner of the "Most thorough misunderstanding of the point of StringBuffer()" award.

brazzy:

This has to be the uncontested winner of the "Most thorough misunderstanding of the point of StringBuffer()" award.

Surely that would go to something I saw earlier today.. (.net so StringBuilder instead of StringBuffer)


StringBuilder sb = new StringBuilder();
sb.Append(customer.FirstName + " " + customer.LastName + "\r\n");

return sb.ToString();

I don't get it. If the code generation "tool" is still around, why can't they add new columns to tables? I mean, the code sure is ugly, but it's generated anyway so it shouldn't be maintained. On the other hand, I don't think that refactoring this (only when needed to add a single column) should be that hard.

Captcha: cogo. Like thinking, but shorter.

Oh, he's using stringbuffer for improved speed! Just concatenating strings would take way too long...
Not a wtf... no... not at all...

I also just saw something similar using Java's String.format():

return String.format ("%d", someInteger) + " blah";

Code writing code?!
What are you trying to put us out of work!!!!!!


{I am quite capable of writing bad code on my own. I don't need a stinkin' machine to do it for me!}

No way can I accept that somebody actually wrote that code thinking it was right.

Are there really programmers out there who are that ignorant?

And to think people grumble about jQuery's ability to chain methods...

Key comments there in the exposition. "Formatted by yours truely" and "This is one of the smaller statements"


This is probably what this smaller statement looks like in the actual source:

new OdbcCommand(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append(new StringBuffer().append("Insert into wc_scanbol values(").append(num).ToString()).append(",'").ToString()).append(bol.BolNum).ToString()).append("',").ToString()).append(Integer.parseInt(bol.get_ShipDate().ToString("yyyyMMdd"))).ToString()).append(",").ToString()).append(bol.Period).ToString()).append(",'").ToString()).append(bol.Consignee.Replace("'", "''")).ToString()).append("',").ToString()).append(bol.Cases).ToString()).append(",").ToString()).append(bol.Bottles).ToString()).append(",").ToString()).append(num).ToString()).append(",").ToString()).append(bol.CustID).ToString()).append(",'").ToString()).append(bol.State).ToString()).append("','')").ToString(), this.con).ExecuteNonQuery();

Talk about something that would be a nightmare to maintain

Kuba:

My first thought was "Looks like abstract art to me". And then I started wishing it was in fact abstract.

Looks more like an abject fart. But I guess that's close enough for some.

Grovesy:

brazzy:

This has to be the uncontested winner of the "Most thorough misunderstanding of the point of StringBuffer()" award.

Surely that would go to something I saw earlier today.. (.net so StringBuilder instead of StringBuffer)


StringBuilder sb = new StringBuilder();
sb.Append(customer.FirstName + " " + customer.LastName + "\r\n");

return sb.ToString();

No, sorry, but this one wins by nineteen lengths.

I know the WTF here isn't specifically about the StringBuffers but it is a WTF to see how many people misuse this functionality. I have a little performance project set up in my dev environment that I pass on to my colleagues whenever they start using StringBuilders (.NET) for string concatenation. It basically shows that you need to be making at least 100 concatenations before the StringBuilder class offers any performance increase over regular string concatenation. This is invariably an order of magnitude greater than the number of concatenations they are actually making. StringBuilder is a widely misunderstood class that, due to its misuse, is probably responsible for hindering performance more often than it improves it.

Peter:

I believe that, when executed, this code can make the universe explode.

I've seen code like that explode a server ... a couple thousand process forks later ...

Anonymous:

I know the WTF here isn't specifically about the StringBuffers but it is a WTF to see how many people misuse this functionality. I have a little performance project set up in my dev environment that I pass on to my colleagues whenever they start using StringBuilders (.NET) for string concatenation. It basically shows that you need to be making at least 100 concatenations before the StringBuilder class offers any performance increase over regular string concatenation. This is invariably an order of magnitude greater than the number of concatenations they are actually making. StringBuilder is a widely misunderstood class that, due to its misuse, is probably responsible for hindering performance more often than it improves it.

http://msdn.microsoft.com/en-us/library/aa302329.aspx:

How the StringBuilder method performs against the standard concatenation method depends on a number of factors, including the number of concatenations, the size of the string being built, and how well the initialization parameters for the StringBuilder buffer are chosen. Note that in most cases it is going to be far better to overestimate the amount of space needed in the buffer than to have it grow often.

....charts 'n shit....

Conclusion

The conclusion to be drawn from these test results is really very straightforward. You should be using the StringBuilder class for all but the most trivial string concatenation (or replace) operations. The extra effort required to use the StringBuilder class is negligible and is far outweighed by the potential performance and scalability benefits to be gained.

And besides that, there is a second WTF: that piece of code is vulnerable to be sql injected :P

Grovesy:

brazzy:

This has to be the uncontested winner of the "Most thorough misunderstanding of the point of StringBuffer()" award.

Surely that would go to something I saw earlier today.. (.net so StringBuilder instead of StringBuffer)


StringBuilder sb = new StringBuilder();
sb.Append(customer.FirstName + " " + customer.LastName + "\r\n");

return sb.ToString();

What I love about this is that after literally laughing out loud, developers will find it utterly impossible to explain to non-developers what they are laughing at.

Wow, that is a WTF.

Braechnov:

What I love about this is that after literally laughing out loud, developers will find it utterly impossible to explain to non-developers what they are laughing at.

While not -impossible- to explain, it's just not going to be funny to them. And while I didn't LOL, I did say 'Nooo!'

MaW:

No way can I accept that somebody actually wrote that code thinking it was right.

Are there really programmers out there who are that ignorant?

short answer: yes.

wtf:

Anonymous:

I know the WTF here isn't specifically about the StringBuffers but it is a WTF to see how many people misuse this functionality. I have a little performance project set up in my dev environment that I pass on to my colleagues whenever they start using StringBuilders (.NET) for string concatenation. It basically shows that you need to be making at least 100 concatenations before the StringBuilder class offers any performance increase over regular string concatenation. This is invariably an order of magnitude greater than the number of concatenations they are actually making. StringBuilder is a widely misunderstood class that, due to its misuse, is probably responsible for hindering performance more often than it improves it.

http://msdn.microsoft.com/en-us/library/aa302329.aspx:

<snipped copypasta>

Right, so you read an MSDN article and I actually created a Visual Studio performance project that uses string concatenation and StringBuilders in several different mocked up "real-world" examples. Sorry, but I think I'll take my actual research over your web page reading skills any day. Your attitude is exactly why StringBuilders are so misused. You think to yourself "well I read it on MSDN so why should I bother doing any actual reasearch into it myself?". Sorry, but real software developers rely on their own testing instead of the say-so of tech websites.

Well, good for you. You actually wrote code and tested something. Do you do this for every function call in every library you use? Or just the ones you're arguing about? I mean, empiricism rules and all, but generally depending on the tech documentation written by the people who actually, you know, designed and wrote the library, is a pretty reasonable thing to do.

The real WTF™ is that when writing this article, someone must have mixed up their Java and C#:

* The class is StringBuffer in Java, and StringBuilder in C#
* ToString (PascalCase) is C#, toString (camelCase) is Java
* append is Java, C# should be Append with a capital 'A'
* Java has an OdbcCommand?
* Java has ExecuteNonQuery?

So do it! I see what the code does for once, I guess the problem is in the /r/n at the end?

I am a non-developer. But I took a class on Java once!

Grovesy:

brazzy:

This has to be the uncontested winner of the "Most thorough misunderstanding of the point of StringBuffer()" award.

Surely that would go to something I saw earlier today.. (.net so StringBuilder instead of StringBuffer)


StringBuilder sb = new StringBuilder();
sb.Append(customer.FirstName + " " + customer.LastName + "\r\n");

return sb.ToString();

Do you mean StringBuffer? If so, StringBuffer is a faster way to do the operation you outlined.

Anonymous:

wtf:

Anonymous:

I know the WTF here isn't specifically about the StringBuffers but it is a WTF to see how many people misuse this functionality. I have a little performance project set up in my dev environment that I pass on to my colleagues whenever they start using StringBuilders (.NET) for string concatenation. It basically shows that you need to be making at least 100 concatenations before the StringBuilder class offers any performance increase over regular string concatenation. This is invariably an order of magnitude greater than the number of concatenations they are actually making. StringBuilder is a widely misunderstood class that, due to its misuse, is probably responsible for hindering performance more often than it improves it.

http://msdn.microsoft.com/en-us/library/aa302329.aspx:

<snipped copypasta>

<snipped rant>

Actually, MSDN agrees with you: the smallest number of concatenations they tested is 350. It's not the most obvious definition of "all but the most trivial string concatenation (or replace) operations", though.

Anonymous:

wtf:

Anonymous:

I know the WTF here isn't specifically about the StringBuffers but it is a WTF to see how many people misuse this functionality. I have a little performance project set up in my dev environment that I pass on to my colleagues whenever they start using StringBuilders (.NET) for string concatenation. It basically shows that you need to be making at least 100 concatenations before the StringBuilder class offers any performance increase over regular string concatenation. This is invariably an order of magnitude greater than the number of concatenations they are actually making. StringBuilder is a widely misunderstood class that, due to its misuse, is probably responsible for hindering performance more often than it improves it.

http://msdn.microsoft.com/en-us/library/aa302329.aspx:

<snipped copypasta>

Right, so you read an MSDN article and I actually created a Visual Studio performance project that uses string concatenation and StringBuilders in several different mocked up "real-world" examples. Sorry, but I think I'll take my actual research over your web page reading skills any day. Your attitude is exactly why StringBuilders are so misused. You think to yourself "well I read it on MSDN so why should I bother doing any actual reasearch into it myself?". Sorry, but real software developers rely on their own testing instead of the say-so of tech websites.

But a key part is this:

How the StringBuilder method performs against the standard concatenation method depends on a number of factors, including the number of concatenations, the size of the string being built, and how well the initialization parameters for the StringBuilder buffer are chosen.

Perhaps you are the one who doesn't know how to use StringBuilder correctly? If you make the StringBuilder big enough to start with, it shouldn't need to resize itself which is it's biggest drain on performance. Why don't you put your money were your mouth is and post your code?
I do, however, agree that you should test your particular situation in your code before you draw any conclusions if you are really concerned about performance.

Wow. Its funny how one's sarcasm is measured by one's own ego.

In my own testing of StringBuilder, I have found the opposite of what you have, but I dont come here to trash someone and feel better about myself doing it.

I like the artist's use of negative space.

Jorge:

And besides that, there is a second WTF: that piece of code is vulnerable to be sql injected :P

Well, not really!

'bol.Consignee' is protected from SQL Injection -- by doubling all apostraphe characters.

'bol.BolNum' and 'bol.State' are not so protected, which may or may not be a problem: If one relies on drop-down selection of values in HTML, then a hacker could do a SQL Injection attack. But if the values are validated on the server before calling insert, then SQL Injection would not be possible.

Peter:

I believe that, when executed, this code can make the universe explode.

I pasted it into Eclipse to refactor it. Eclipse locked up!!! Yes, it really did!!!

(So while it didn't destroy the universe, it certainly destroyed the sun! (...or maybe just the moon. ;-)

> customer.FirstName + " " + customer.LastName + "\r\n"

The 'customer.getFirstName() + " " + customer.getLastName() + "\r\n"' in Java gets compiled in:

sb.append(customer.getFirstName())
sb.append(" ")
sb.append(customer.getLastName())
sb.append("\r\n")

Vempele:

Anonymous:

wtf:

Anonymous:

I know the WTF here isn't specifically about the StringBuffers but it is a WTF to see how many people misuse this functionality. I have a little performance project set up in my dev environment that I pass on to my colleagues whenever they start using StringBuilders (.NET) for string concatenation. It basically shows that you need to be making at least 100 concatenations before the StringBuilder class offers any performance increase over regular string concatenation. This is invariably an order of magnitude greater than the number of concatenations they are actually making. StringBuilder is a widely misunderstood class that, due to its misuse, is probably responsible for hindering performance more often than it improves it.

http://msdn.microsoft.com/en-us/library/aa302329.aspx:

<snipped copypasta>

<snipped rant>

Actually, MSDN agrees with you: the smallest number of concatenations they tested is 350. It's not the most obvious definition of "all but the most trivial string concatenation (or replace) operations", though.

Well, on that point I would agree with the article. If you are using concatenation in a loop from 1 to 10, then the performance does not matter - so you should use StringBuffer so that it doesn't explode if for some reason later it somehow gets called 100000 times.

"The goggles, they do nothing!"

Vempele:

Anonymous:

wtf:

Anonymous:

I know the WTF here isn't specifically about the StringBuffers but it is a WTF to see how many people misuse this functionality. I have a little performance project set up in my dev environment that I pass on to my colleagues whenever they start using StringBuilders (.NET) for string concatenation. It basically shows that you need to be making at least 100 concatenations before the StringBuilder class offers any performance increase over regular string concatenation. This is invariably an order of magnitude greater than the number of concatenations they are actually making. StringBuilder is a widely misunderstood class that, due to its misuse, is probably responsible for hindering performance more often than it improves it.

http://msdn.microsoft.com/en-us/library/aa302329.aspx:

<snipped copypasta>

<snipped rant>

Actually, MSDN agrees with you: the smallest number of concatenations they tested is 350. It's not the most obvious definition of "all but the most trivial string concatenation (or replace) operations", though.

Someone actually tested this and posted results with 8+ strings StringBuilder is more efficient. So if there is a chance of using 8+ strings ever use StringBuilder.

OH I remember working with a programmer like steve. We were sending emails from VB.NET, I told him to use a string builder because there was a table in there.

And so he did, the entire auto generated email was a long chain of calls to the same string builder (at least it was the *same* one).

I changed that for a custom template text file.

Anonymous:

Right, so you read an MSDN article and I actually created a Visual Studio performance project that uses string concatenation and StringBuilders in several different mocked up "real-world" examples. Sorry, but I think I'll take my actual research over your web page reading skills any day. Your attitude is exactly why StringBuilders are so misused. You think to yourself "well I read it on MSDN so why should I bother doing any actual reasearch into it myself?". Sorry, but real software developers rely on their own testing instead of the say-so of tech websites.

Alright then, I wrote a little test myself to generate random strings of random length, concatenate those strings once each way, and repeat the entire process 100 times and take the average ticks. Here are my test results:

Running test: 2 strings, max length 10

Total length: 8.98

Straight concatenation time: 123.85

Builder (no capacity): 14.90



Running test: 10 strings, max length 10

Total length: 54.00

Straight concatenation time: 32.90

Builder (no capacity): 23.28



Running test: 100 strings, max length 10

Total length: 499.83

Straight concatenation time: 838.09

Builder (no capacity): 122.18



Running test: 1000 strings, max length 10

Total length: 4985.17

Straight concatenation time: 24233.43

Builder (no capacity): 998.58



Running test: 2 strings, max length 100

Total length: 68.00

Straight concatenation time: 17.53

Builder (no capacity): 13.77



Running test: 10 strings, max length 100

Total length: 467.24

Straight concatenation time: 49.91

Builder (no capacity): 31.85



Running test: 100 strings, max length 100

Total length: 5013.23

Straight concatenation time: 2405.58

Builder (no capacity): 241.97



Running test: 1000 strings, max length 100

Total length: 49857.29

Straight concatenation time: 443585.78

Builder (no capacity): 3544.84



Running test: 2 strings, max length 1000

Total length: 887.00

Straight concatenation time: 21.80

Builder (no capacity): 22.87



Running test: 10 strings, max length 1000

Total length: 5780.02

Straight concatenation time: 470.20

Builder (no capacity): 193.95



Running test: 100 strings, max length 1000

Total length: 49758.02

Straight concatenation time: 45279.72

Builder (no capacity): 3024.95

Seems to support the StringBuilder being a full order of magnitude faster, even for relatively small numbers of concatenations and relatively small strings. For very large numbers of concatenations, like for example an in-memory log or writing out markup or something, I can see a difference of almost two full orders of magnitude. As you would expect, the StringBuilder time grows linearly while straight concatenation time grows exponentially.

The only edge case seems to be when the total length is around 50 characters, and even then the StringBuilder is still a little faster. I can imagine that there might be some very specific circumstances under which it would be slower, but certainly not by a wide margin. And a standard error message or database command is probably going to be at least a few hundred characters, so the case of 50 characters is essentially irrelevant anyway.

This took me all of 5 minutes. Just reading the MSDN documentation (assuming I didn't already know the answer, which I did) would have taken 10 seconds. I'm guessing that you did the majority of your "research" in your ass.

ObiWayneKenobi:

The real WTF™ is that when writing this article, someone must have mixed up their Java and C#:

* The class is StringBuffer in Java, and StringBuilder in C#
* ToString (PascalCase) is C#, toString (camelCase) is Java
* append is Java, C# should be Append with a capital 'A'
* Java has an OdbcCommand?
* Java has ExecuteNonQuery?

Acknowledging the last four items, Java has both StringBuffer and StringBuilder. Check the javadoc: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html

[quote=ObiWayneKenobi]
The real WTF™ is that when writing this article, someone must have mixed up their Java and C#:

* The class is StringBuffer in Java, and StringBuilder in C#
* ToString (PascalCase) is C#, toString (camelCase) is Java
* append is Java, C# should be Append with a capital 'A'
* Java has an OdbcCommand?
* Java has ExecuteNonQuery?
[/quote]

Java also has StringBuilder as a non-thread-safe version of StringBuffer since version 1.5. That doesn't excuse the other issues, though.

OH FUCK WHY DOES THAT ALWAYS HAPPEN???????

Vempele:

Actually, MSDN agrees with you: the smallest number of concatenations they tested is 350. It's not the most obvious definition of "all but the most trivial string concatenation (or replace) operations", though.

QED. But I'm hardly surprised that Microsoft agree wtih me, my results are sound and my perfomance testing routines always follow real-world patterns. My results are from a large number of different string concatenation tests and the "100 concatenations" figure comes from an average of all of them. This example is too trivial to truly exercise the relevant classes so I'm not surprised at the totally inaccurate results they came up with. And to the person who wanted to see my test routines, I'll gladly share them with you but you'll have to sign our NDA.

OK, that first result looks a little off, I think it must be some jitting artifact. Changed it to run the first test twice and here's the result:

Running test: 2 strings, max length 10

Total length: 12.39

Straight concatenation time: 105.08

Builder (no capacity): 13.71



Running test: 2 strings, max length 10

Total length: 13.00

Straight concatenation time: 16.17

Builder (no capacity): 17.58

So it looks like for the most trivial possible concatenation, the StringBuilder takes 9% longer. If you're doing exactly 2 concatenations of very short strings in a tight loop, you might want to use regular concatenation (duh).

Aaron:

<snipped garbage test results>

Aaron:

OK, that first result looks a little off, I think it must be some jitting artifact.... So it looks like for the most trivial possible concatenation, the StringBuilder takes 9% longer....

Thanks for your utterly useless test results, glad you wasted our time here.

Anonymous:

QED. But I'm hardly surprised that Microsoft agree wtih me, my results are sound and my perfomance testing routines always follow real-world patterns. My results are from a large number of different string concatenation tests and the "100 concatenations" figure comes from an average of all of them. This example is too trivial to truly exercise the relevant classes so I'm not surprised at the totally inaccurate results they came up with. And to the person who wanted to see my test routines, I'll gladly share them with you but you'll have to sign our NDA.

Okay, now I'm sure of it - TopCod3r is back.

Anonymous:

And to the person who wanted to see my test routines, I'll gladly share them with you but you'll have to sign our NDA.

How convenient. That way you don't have to show that you're talking out your ass and don't know how to use StringBuilder. Put up or shut up.

Anonymous:

Aaron:

<snipped garbage test results>

Aaron:

OK, that first result looks a little off, I think it must be some jitting artifact.... So it looks like for the most trivial possible concatenation, the StringBuilder takes 9% longer....

Thanks for your utterly useless test results, glad you wasted our time here.

It's great how you chastise somebody for looking it up on MSDN and not writing a real test app and then you chastise somebody else for writing a test app.
TopCod3r is back!