• Dan Tastic (unregistered) in reply to Charles F.

    It seems to me they are not trying to access a database using Spring and Hibernate. At least we can say this method is not as stupid and not as inefficient as a Springbernate nightmare... Glass is half full :)

  • (cs) in reply to Kayaman
    Kayaman:
    As an experienced Java programmer (~15yrs), I find it funny when people talk about efficiency, when they mean "useless micro-optimization in a piece of WTF code".

    If I had a dollar for every time I found code where it did something overly complex to save very little time, and then did something like not break out of a complex loop once a certain condition is met, I could probably at least pay for lunch today.

  • (cs)

    Wooooooooooooooooooooooooooo! My submission got posted - like 5 years later, but who cares! I should totally out the developer...

  • onedaywhen (unregistered)

    "Data-driven applications need to generate SQL from time to time... from time to time, we might hard code our SQL statements"

    That's TRWTF, right there.

  • englebart (unregistered) in reply to JJ
    JJ:
    Zylon:
    $$ERR:get_name_fail:
    OPEN_PARENTHESIS = '('
    And even worse, misspelled variable names.
    NotSureIfTrolling.jpg

    What exactly do you consider misspelled about that "variable" name? (The only misspelling I see is that "variable" should be "constant".)

    Unless you are coding XSLT where they call constants variables! Don't ask me why... I wasted a bunch of hours on my first XSLT trying to update variables... which are constants... and immutable... and I am still peeved... can you tell?

  • chentiangemalc (unregistered) in reply to Charles F.

    um in C# constants are concatenated at compile time too. but the purpose of StringBuilder is designed to be used for strings not known at compile time. in this case Java couldn't guess what they are either. for strings not known at compile time stringbuilder in .net is very efficient memory & cpu wise.

  • (cs) in reply to Charles F.

    and you'd be wrong. StringBuilder can be very useful when constructing strings, especially strings with variable number of variable parts. The ONLY WTF here is the assumption that the syntax of SQL commands has to be abstracted away because of some rule about not using any String literals because those might change over time while the grammar of SQL is considered to be set in stone. A true statement builder would have things like an appendInnerJoin(Condition condition) method for example rather than doing statement.append(INNERJOIN).append(...).append(...). :)

  • Duh (unregistered) in reply to Charles F.

    Hey Charles, what is it like working with Adam?

  • instigator (unregistered) in reply to Jorge

    Not that I agree with your PM, but there are some good open source libraries that will build sql queries for you. They will allow you to do anything you can with a string literal. To comply with your PM you would still need to define constants for column names, but that is a good practice anyway.

  • instigator (unregistered) in reply to commoveo
    Jorge: This is actually happening to me. The project manager insist that if it is a string, then it has to be a constant and the rest of the code should reference the constant. And there is not way to reason with this guy, he wants to rule applied globally and blindly.

    Does he not know that the .NET compiler does that automatically with string literals?

    I believe you missed the point. The idea is to be able to change string literals more easily (particularly when they are referenced often). His PM is being pedantic about this rule, as the SQL keywords are not likely to change.

  • instigator (unregistered) in reply to Charles F.
    In Java, concatenation of String literals occurs at compile time. Instead of being stupid and inefficient, this method could at least be stupid and efficient.

    TRWTF is trying to micro-optimize JAVA!

  • James (unregistered) in reply to Charles F.

    But I thought that using the StringBuilder class prevented an object being wastefully generated by the JVM for each concatenated string.

  • Rodrigo (unregistered)

    Actually we found a similar WTF in a code we recently inhereted, but with a plethora of added twists (which are WTFs in their own glory). Instead of simply inserting, updating or doing whatever the heck you're doing right away, the query gets queued to be executed at some time the "db framework" deems right. Oh, and inserts, updates and deletes are stored in separate queues and executed concurrently, creating a set of fun and challenging out-of-order problems where there were none.

    Did I mention they get executed concurrently? Somehow having a single database but impacting it in parallel feels faster and more pro.

    Not to mention that when you need to delete 10000 rows, you instead launch 5 threads that request removal of 2000 each, thus harnessing the true powa of multithreading!

    Beat that enterpriseyness!

  • Rachel Pierson (unregistered) in reply to Charles F.

    I don't know about Java, but in .Net StringBuilder appends are used to save memory. StringBuilder avoids copying strings merely to concatenate them, which would otherwise happen if you just instead said:

      myString += "some value"

    This is because the String data type is immutable in .Net : it acts like a Value type, but it really isn't one (it can't be, since strings can't be of a fixed and predetermined length, which means they're actually implemented as a Reference type and stored on the Managed Heap). So, when you run a line like the one above what happens is that a new copy of the longer concatenated string gets assigned to myString, and the old data that used to be referenced by the myString variable gets left behind in the Heap for later cleanup by the Garbage Collector. If you do that type of concatenation a lot, you get a slow app with memory management issues.

    The RWTF in the above isn't that it uses StringBuilder's append method. The RWTF is as suggested by the article: it'd have been far easier just to write the damn SQL clearly. The only case I can see for the implementation above is that it would allow you to rename table columns easily if you wanted to in the future. But then, that's what CTRL+H is for.

  • Paul (unregistered) in reply to Charles F.

    Ok, I would like to point out that append calls are a waste of time, and Java can do string concatenation at compile time.

    Are we home yet?

  • MaxiTB (unregistered) in reply to Charles F.

    This is C#, no Java. StringBuilder is way faster because strings are unique.

  • MaxiTB (unregistered) in reply to Charles F.

    Nvm, it's Java, I missed the small t. So performance is not relevant to begin with. The main WTF is the readability. Bad performance and unreadable code.

  • Piper (unregistered)

    This looks like what happens when a style guide prohibition of "magic constants" is interpreted to mean no literals of any kind anywhere ever.

  • Altourus (unregistered) in reply to Charles F.
    Charles F.:
    I'm surprised that no one has pointed out that the the StringBuilder and append calls are a complete waste of CPU and memory. In Java, concatenation of String literals occurs at compile time. Instead of being stupid and inefficient, this method could at least be stupid and efficient.

    I beleive the code referenced here is actually C# in which case the StringBuilder reduces the use of CPU and Memory that occurs from string Concatination

    http://www.dotnetperls.com/stringbuilder

  • ORM tools (unregistered)

    Did anyone notice the unicorn easter egg?

Leave a comment on “InsertSql()”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article