• Anonymous (unregistered) in reply to Anon
    Anon:
    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.
    Sorry but no amount of pouting is going to reverse our NDA. If you worked in the Aerospace industry you'd understand.
  • (cs)

    Why doesn't Dan D write some code-rewriting code? Does his manager now fetch the garlic and the stake when someone mentions code generation?

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

    I'm going to guess your code looks something like this:

    string test = "oh " + "my " + "god " + ", " + "this " + "is " + "faster";

    StringBuilder sb = new StringBuilder(1); sb.Append("oh "); sb.Append("my "; sb.Append("god "); sb.Append(", "); sb.Append("this "); sb.Append("is "); sb.Append("slower "); sb.ToString();

  • Anonymous (unregistered) in reply to Anon
    Anon:
    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!
    Actually, I chastised him because by his own admission his test results were wrong. Plus, I question the effectiveness of the tests he would have come up with in his "five minutes". I have a whole suite of performance tests for this, from which I have derived the figures I'm using. Try reading the comments, would you?
  • (cs) 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.
    An NDA for a simple StringBuilder performance test? Go troll some other forum with your bogus results. What kind of magical string concatenation situation do you encounter in your so-called real life application?

    At least Aaron backed up his claims.

  • Anonymous (unregistered) in reply to bjolling
    bjolling:
    An NDA for a simple StringBuilder performance test?
    No, it's an NDA for every single piece of work I produce at this company, irrespective of whether its a code file or a Word document. What the hell do you expect from and Aerospace and military subcontractor?
  • (cs)

    I too am wondering (1) how come they can't just rerun the code generation tool when the database changes and (2) why they can't fix the code generation tool and then rerun it.

  • Anon (unregistered) in reply to Anonymous
    Anonymous:
    Anon:
    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!
    Actually, I chastised him because by his own admission his test results were wrong. Plus, I question the effectiveness of the tests he would have come up with in his "five minutes". I have a whole suite of performance tests for this, from which I have derived the figures I'm using. Try reading the comments, would you?

    He admitted that the first result looked wrong and tested it again. Then he posted both results. That's called integrity. Most people would have ignored the first result. That said, he should run the test a large number of times (maybe 100) and then post the averages to reduce the effects of one off quirks like jitting delays or some other unexpected interruption. You have still posted no results and no code and can't show anything to back up your claims despite two links and one post all showing the opposite. So I'd say if most cases (except Mr. Anonymous super special aeronautic apps), StringBuilder is demonstrably faster for all but the smallest string concatenations.
    Everybody note: if you are working in aeronautics, make sure you use string concatenation. Aeronautics is special and the regular laws of physics don't apply.

  • (cs) in reply to Anonymous
    Anonymous:
    bjolling:
    An NDA for a simple StringBuilder performance test?
    No, it's an NDA for every single piece of work I produce at this company, irrespective of whether its a code file or a Word document. What the hell do you expect from and Aerospace and military subcontractor?
    Should've kept your results to yourself then :-|
  • puzzled (unregistered) in reply to Anon
    Anon:
    Everybody note: if you are working in aeronautics, make sure you use string concatenation. Aeronautics is special and the regular laws of physics don't apply.

    Now thats funny

  • (cs) 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?

    Agreed. Items 2 & 3 means that this wouldn't compile in either language. I'm calling BS.

  • Anonymous (unregistered) in reply to bjolling
    bjolling:
    Should've kept your results to yourself then :-|
    But then I couldn't have taught you all this very important lesson. You're welcome.
  • (cs) 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?
    • Java can haz cheezburger
  • (cs) in reply to Anonymous
    Anonymous:
    bjolling:
    Should've kept your results to yourself then :-|
    But then I couldn't have taught you all this very important lesson. You're welcome.

    Yes, but if all of your work is covered by the NDA, haven't you violated it by posting the results?

    And by your own words, this lesson would hardly qualify as "very important". Apparently, the difference between the two is so negligible that unless you're writing an app to do nothing but concat strings all day, it doesn't matter what you use.

    Even considering that logic, the concat operator is fugly. In a sea of well written, elegant code...a concat operator stands out like a rear view mirror duct-taped to a Ferrari.

  • (cs) in reply to Anon
    Anon:
    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!
    Nah. TopCod3r never chastises anybody. He just sets out bait and watches the unwary prey get ensnared.

    TRWTF is coders having an extended argument over use of StringBuilder.

  • mjfgates (unregistered)

    At my current job, there was a guy who wrote code that looks a lot like the original WTF. Except he did it by hand. And since we're in VB6, he had to write his own StringBuilder class first.

  • (cs)

    I wish books about basic programming did not mention StringBuffer / StringBuilder at all. SB only makes sense in loops and recursiion and such. Programmers who don't understand strings are less likely to do harm if they don't know about SB. What is more some book authors don't understand how string concatenation works. I've seen books that advise using SB if you have more than 3 + concatenations. WTF?!

  • (cs) in reply to Anon
    Anon:
    That said, he should run the test a large number of times (maybe 100) and then post the averages to reduce the effects of one off quirks like jitting delays or some other unexpected interruption.
    I actually did - or rather, that's what the program does, runs the test 100 times with new data each time - but I think for that first result there was some really huge jitting delay that managed to skew the entire average.

    I'm more than happy to post the "performance testing" code - I am certainly not bound by any NDA. But I have a strong feeling that Mr. Anonymous is just trolling; the giveaway was his comment about other tests not "exercising the relevant parts".

  • (cs) in reply to Anonymous
    Anonymous:
    Sorry but no amount of pouting is going to reverse our NDA. If you worked in the Aerospace industry you'd understand.

    Sorry, but no amount of BS is going to get you off the hook.

    An NDA for a StringBuilder vs. concatenation benchmark? Who are you trying to kid?

    Why should anyone to believe you when you

    • post using "Anonymous" so people can't differentiate you from every other troll

    • post nonsense drivel about benchmarks you can't back up

    • claim you can't post your benchmark code because of NDAs (which is utterly ridiculous)

    • have a benchmark (that you can't produce, of course) that totally disagrees with the makers of the library's own benchmarks (which they provide code to justify)

    Come back when you actually have something to say. Right now, you're just spewing senseless, useless noise.

  • (cs) in reply to Stilgar
    Stilgar:
    I wish books about basic programming did not mention StringBuffer / StringBuilder at all. SB only makes sense in loops and recursiion and such. Programmers who don't understand strings are less likely to do harm if they don't know about SB. What is more some book authors don't understand how string concatenation works. I've seen books that advise using SB if you have more than 3 + concatenations. WTF?!
    That's why I like Python. Just use a list. No need for a special 'builder' class, just a generic container to hold strings while building them up. And for any bounded string concatenation, I probably wouldn't even bother with a build operation at all. I'd say more, but my NDA is choking my scrote blue already.
  • (cs) in reply to ObiWayneKenobi

    This does seem to be a mix of java and c#. Maybe the code is compiled with IKVM which allows java code to use the c# library (and thus .toString() would be an alias to .ToString())

  • (cs) in reply to Anonymous
    Anonymous:
    No, it's an NDA for every single piece of work I produce at this company, irrespective of whether its a code file or a Word document. What the hell do you expect from and Aerospace and military subcontractor?

    I expect them to employ people who actually know what they're talking about, and not people like you who blow smoke.

    Who do you really work for?

  • lmao (unregistered) in reply to Anonymous
    Anonymous:
    bjolling:
    An NDA for a simple StringBuilder performance test?
    No, it's an NDA for every single piece of work I produce at this company, irrespective of whether its a code file or a Word document. What the hell do you expect from and Aerospace and military subcontractor?

    Clearly, that NDA must also include these asinine comments?

    "[Anonymous] then goes on to prove that black is white and gets himself killed at the next zebra crossing."

    And there was much rejoicing.

  • TRWTF (unregistered) in reply to MrBester
    MrBester:
    And to think people grumble about jQuery's ability to chain methods...

    sigh

    Alright. I'll play your silly little game: TRWTF™ is jQuery.

  • Robert S. Robbins (unregistered)

    Cool! That code doubles as ASCII art. Proof that programming can be an art.

  • Guy who's programmed Apple IIs (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.

    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.

    The 2Gb RAM you bought to get the latest Windows to run is already invested. So, why not use StringBuilder and eat up that RAM?

  • Anon (unregistered) in reply to Guy who's programmed Apple IIs
    Guy who's programmed Apple IIs:
    The 2Gb RAM you bought to get the latest Windows to run is already invested. So, why not use StringBuilder and eat up that RAM?

    I think you'll find that since .NET (and Java) is garbage collected, you'll eat up less memory using StringBuilder (especially if you set the capacity to something sensible). If you look at the graphs in the link you'll see that the garbage collector is invoked much less often with StringBuilder than with string concatenation because all those copies of strings are stuck taking up memory and waiting for collection.

  • (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.
    I won't, because apparently you don't know how to test. Using the code:

    static long NUM_LOOPS = 1000000; static long NUM_APPENDS = 100; static String APPEND_STRING = "something";

    static void Main(string[] args)
    {
      DateTime before = DateTime.Now;
      for (int loops = 0; loops < NUM_LOOPS; ++loops)
      {
        StringBuilder sb = new StringBuilder();
        for (int appends = 0; appends < NUM_APPENDS; ++appends)
          sb.Append(APPEND_STRING);
        sb.ToString();
      }
      DateTime after = DateTime.Now;
    
      System.Console.Write(after - before);
    
      before = DateTime.Now;
      for (int loops = 0; loops < NUM_LOOPS; ++loops)
      {
        String s = "";
        for (int appends = 0; appends < NUM_APPENDS; ++appends)
          s += APPEND_STRING;
      }
      after = DateTime.Now;
    
      System.Console.Write(after - before);
    }
    

    StringBuilder = 4.28s, String = 32.8s

    Changing NUM_APPENDS to 10: StringBuilder = .61s String = .8s

    Changing it again to 5: StringBuilder = .33s String = .27s

    Your attitude is exactly why StringBuilders are... oh nevermind, it's just easier to call you stupid.

  • (cs) in reply to Aaron
    Aaron:
    Okay, now I'm sure of it - TopCod3r is back.
    s/Top/Slop/

    TopCod3r at least was sometimes funny...

    np: Near The Parenthesis - Nidae (Intelligent Toys 4)-

  • You-do-not-want-to-know (unregistered) in reply to andrewbadera
    andrewbadera:
    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 ...

    I've had the pleasure to see a system explode for real - like in the movies, with fire and smoke et al. It was on an oil rig where I was installing a monitoring system for mooring lines, and I had received serious management grief for insisting on optical isolators in our 4 PC unit (they cost money, and it was deemed over the top).

    The guys who were supposed to supply us with wind data also handled generator power, and just finished rigging. Their PC based system powered up, hard disks started spinning, OS loaded, the core apps started, preparing for data acquisition. As soon as the relays on the data acquisition card clicked in, the thing literally exploded internally - we're talking about a system case that ended up being rounder than designed, and I actually never expected that possible. I presume it must have been capacitors that provided the bang.

    We heard later that a wiring mistake had been responsible. The DA was supposed to have been fed off a normal 20mA loop, but was instead patched straight into some 480V power line, hence the enthusiasm when the relays allowed this into unprotected circuitry.

    Complaints about optical isolators disappeared :-).

  • (cs) in reply to Guy who's programmed Apple IIs
    Guy who's programmed Apple IIs:
    The 2Gb RAM you bought to get the latest Windows to run is already invested. So, why not use StringBuilder and eat up that RAM?
    Another troll post? Strings are immutable and thus require a new memory allocation for the result of each and every regular concatenation. A StringBuilder uses one and only one buffer that grows dynamically, or not at all if you set the capacity parameter properly.

    In fact, the memory characteristics of concatenation vs. StringBuilder are the same as the running time characteristics; memory usage will grow more or less exponentially with the number of concatenations.

    (I say "more or less" because eventually the garbage collector will kick in and free all of that memory, except for the one result string that's still assigned, which takes up exactly as much memory as the StringBuilder would be taking up.)

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

    oh sweet jesus, i hope you just forgot to wrap that statement in sarcasm tags. you may have not looked close enough so im going to point it out to you, THATS NOT ACTUALY USING A STRINGBUILDER ITS DOING string str = customer.FirstName + " " + customer.LastName + "\r\n"; sb.Append(str);

    sorry for yelling but you shouldn't say things like that, its scary.

  • 01001001011101000010011101110011001000000110110101100101 (unregistered) in reply to Shial
    Shial:
    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

    Actually this would be simple to maintain. The first time it needs to be modified you simply throw this crap away and write something better in its place. I'll never understand why people will jump through hoops to avoid fixing crap.... Surely overloading columns is more difficult and harder to maintain than just replacing this BS in the first place....

  • Dan (unregistered)

    Hmmm, I wonder if this code was inspired by a book on optimizing Java? I read one in the 1.4 days, which pointed out how the compiler handles string concatenation by creating a string buffer, appending the first side and then the second side, then converting it back to a string, and would do this for each pair, even in a multiple concatenation. So the author said to use StringBuffer yourself and don't convert toString until afterwards, and showed timing loops to support the claim.

    Of course this example seems to be the exact opposite of that advice, so maybe he read the book backwards...

  • itzfritz (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.
    TRWTF is that you don't understand the basic nature of StringBuilder's advantage over String, so you designed a meaningless 'performance project' to show a conclusion that is equally as meaningless. A String is immutable, which means that concatenation destroys the original String object and spawns a new String object. Just because your testapp says that, on your platform and configuration, a StringBuilder is not every really necessary, doesn't make it true. Not by a wide margin. "A widely misunderstood class" indeed.
  • (cs) in reply to subanark

    C# version that compiles and runs:

      new OdbcCommand(new StringBuilder()
        .Append(new StringBuilder()
         .Append(new StringBuilder()
          .Append(new StringBuilder()
           .Append(new StringBuilder()
            .Append(new StringBuilder()
             .Append(new StringBuilder()
              .Append(new StringBuilder()
               .Append(new StringBuilder()
                .Append(new StringBuilder()
                 .Append(new StringBuilder()
                  .Append(new StringBuilder()
                   .Append(new StringBuilder()
                    .Append(new StringBuilder()
                     .Append(new StringBuilder()
                      .Append(new StringBuilder()
                       .Append(new StringBuilder()
                        .Append(new StringBuilder()
                         .Append(new StringBuilder()
                          .Append(new StringBuilder()
                          .Append("Insert into wc_scanbol values(")
                          .Append(num).ToString())
                         .Append(",'").ToString())
                        .Append(bol.BolNum).ToString())
                       .Append("',").ToString())
                      .Append(Int16.Parse(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();
    
  • Bobbo (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.

    Can I see this NDA please? I have my agreement-signing pen here ready to go. (It's blue ink, I'm assuming that's okay?)

  • Real-modo (unregistered) in reply to wtf
    wtf:

    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 extra effort required to use the StringBuilder class is negligible and is far outweighed by the potential performance and scalability benefits to be gained.

    This is a language design WTF C-hash shares with Java. The "natural" (and more concise) way to do something ought to be the right way to do it. The compiler should take care of the details.

    "Extra effort" should only be required for doing things wrong.

  • (cs)

    He combined the memory waste of string concatenations with the uglyness of StringBuffer! It's things like this that tell you you're dealing with a genious instead of a mere mortal...

  • Capt. Oblivious (unregistered) in reply to Aaron

    I don't do Java or C#. What does StringBuilder/Buffer do to increase concatenation speed? Keep references to raw data values and (maybe lazily) print them when needed? That would certainly be faster than copying arrays of chars...

  • (cs) in reply to Capt. Oblivious
    Capt. Oblivious:
    I don't do Java or C#. What does StringBuilder/Buffer do to increase concatenation speed? Keep references to raw data values and (maybe lazily) print them when needed? That would certainly be faster than copying arrays of chars...
    Basically StringBuilder/Buffer treats a string as a large buffer of characters.

    In C# and java Strings are immutable. So to do A + B; A new string is created, contents of A are copied, contents of B are copied. Fairly slow. Each time you need to append a string, BOTH strings are copied. But a StringBuilder is a mutable string. Basically a big buffer is created. As long as their is room in the buffer, the new string is just attached onto the end.

  • (cs)

    post = "

    various people:
    <snipped snips>
    "; post.append("I'm not sure that I entirely agree.");

  • common sense (unregistered)

    And how long have you been working with this? Theres a WTF right there

  • David (unregistered) in reply to Anonymous
    Anonymous:
    Anon:
    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.
    Sorry but no amount of pouting is going to reverse our NDA. If you worked in the Aerospace industry you'd understand.

    Mental note: avoid work in aerospace industry.

  • common sense (unregistered) in reply to andrewbadera

    not in java you haven't

  • common sense (unregistered)

    Can I suggest that in the time you spent telling the world your problems you could have tweaked the code generator and fixed the problem. Another example of a developer who complains but never fixes.

  • Ratchetr (unregistered) in reply to common sense
    common sense:
    Can I suggest that in the time you spent telling the world your problems you could have tweaked the code generator and fixed the problem. Another example of a developer who complains but never fixes.
    My guess is the code generator isn't worth saving. It was probably written in the .NET 1.0 days, when writing a DAL was rather tedious and repetitive. But Steve wasn't the only one working on a solution. M$ was as well. In .NET 2.0 we got typed datasets. Then came LINQ, followed by the entity framework. Any one of these solutions (even if they do generate bloated code), have to be better than Steve's solution. And you shouldn't have to do a melt and re-pour here. Just replace stuff on an as needed basis.

    To me, the real WTF is this:

    the data-access layer has become an unmaintainable disaster – so much so that, rather than add a new database column, developers have “split” single fields into multiple through bit-shifting and string manipulation
    The original solution obviously stinks. Now add in bit-shifting and string manipulation...things can only get worser and worser from here.
  • (cs)

    Somebody explain to me again why data-access code is boring and repetitive?

  • tation (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();

    The code in the article looks to .NET (upper case T on ToString).

  • vulputate (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#
    Nope, the class is StringBuffer if you want thread safe or StringBuilder if you don't want thread safe (or neither if they are constants. The the compiler will do it).

Leave a comment on “The Great Code Spawn”

Log In or post as a guest

Replying to comment #241408:

« Return to Article