• (cs)

    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.

  • Peter (unregistered)

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

  • Bonanza (unregistered) in reply to Mr B
    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.

  • (cs)

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

  • (cs)

    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.

  • (cs)

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

  • (cs) in reply to brazzy
    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();

  • Osno (unregistered)

    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.

  • ath (unregistered)

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

  • krupa (unregistered) in reply to Grovesy

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

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

  • (cs)

    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!}

  • MaW (unregistered)

    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?

  • (cs)

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

  • (cs)

    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

  • Bo (unregistered) in reply to Kuba
    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.

  • (cs) in reply to Grovesy
    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.

  • Anonymous (unregistered)

    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.

  • (cs) in reply to Peter
    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 ...

  • wtf (unregistered) in reply to Anonymous
    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.

    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.

  • Jorge (unregistered)

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

  • (cs) in reply to Grovesy
    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.

  • Brent (unregistered)

    Wow, that is a WTF.

  • WC (unregistered) in reply to Braechnov
    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!'

  • (cs) in reply to MaW
    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.

  • Anonymous (unregistered) in reply to wtf
    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.
    <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.
  • Anonymous (unregistered)

    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.

  • (cs)

    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?
  • Justin (unregistered) in reply to Braechnov

    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!

  • SatanClaus (unregistered) in reply to Grovesy
    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.

  • (cs) in reply to Anonymous
    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.
    <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.
  • Anon (unregistered) in reply to Anonymous
    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.
    <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.

  • DiverKas (unregistered) in reply to Anonymous

    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.

  • Yoko (unregistered)

    I like the artist's use of negative space.

  • (cs) in reply to Jorge
    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.

  • (cs) in reply to Peter
    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. ;-)

  • Anonymous Coward (unregistered) in reply to Grovesy

    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")

  • Uhh (unregistered) in reply to Vempele
    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.
    <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.

  • BlindedByTheCode (unregistered)

    "The goggles, they do nothing!"

  • Crash (unregistered) in reply to Vempele
    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.
    <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.

  • rgz (unregistered)

    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.

  • (cs) in reply to Anonymous
    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.

  • j (unregistered) in reply to ObiWayneKenobi
    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

  • Anonymous Coward (unregistered) in reply to ObiWayneKenobi

    [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.

  • Anonymous Coward (unregistered) in reply to Anonymous Coward

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

  • Anonymous (unregistered) in reply to Vempele
    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.
  • (cs) in reply to Aaron

    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).

  • Anonymous (unregistered) in reply to Aaron
    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.
  • (cs) in reply to Anonymous
    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.
  • Anon (unregistered) in reply to Anonymous
    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.

  • Anon (unregistered) in reply to Anonymous
    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!

Leave a comment on “The Great Code Spawn”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article