• HAL (unregistered)
    Return "Need to fix this"
    I'm sorry, Dave. I'm afraid I can't do that.
  • Larry (unregistered)

    The problem with regexen is a lot like the problem with library functions: you can never be entirely sure what they're doing. So, in cases like this where the results are important, it is safest to write your own.

  • Smug Unix User (unregistered)

    If you comment your code you can get a good idea of what the function should be doing. If you didn't get the arcane syntax of a regular expression just right then the next developer will at least know what you are trying to do and make the appropriate adjustments. Sometimes code need to have the bugs removed and the same is true of regular expression. A lot of developers will simply look at the expression guess at what it was trying to do and either replace it with something like this example or somehow work around the problem. Writing code is a lot easier than reading it.

  • Herman (unregistered)

    I'm actually interested in the execution path of the searchstring when the database server is able to parallelize the unions and each of the searchfields are indexed.

  • VB_adict (unregistered)

    "turning option strict on for a large project"

    Ha! There is the TRWTF.

    Or maybe its Visual Basic (someone had to say this)

  • asdf (unregistered)

    the existence of the OR operator

    Some people learn what OR operator does (on certain databases) with indices sooner, some later. Union still has a place in SQL as a poor's man OR.

  • Quosek (unregistered)

    in same cases using unions instead of OR really makes a sense - sometimes it's better from performance point of view use unions ....

  • planB (unregistered)

    Nonody noticed the order by only has an efect on the last select of the unions. i guess that's not the effect the developer was going for

  • recently departed colleague (unregistered)

    Hey Chris, sorry for all the injections, but please think a bit and may be you will realize that on old systems UNION worked faster than OR.

    captcha valid lol

  • planB (unregistered) in reply to planB

    Nonody = Nobody

  • lanmind (cs) in reply to Herman
    Herman:
    I'm actually interested in the execution path of the searchstring when the database server is able to parallelize the unions and each of the searchfields are indexed.

    I think, in the case of SQL Server, that the optimizer really only looks at the first query in UNIONs to do its magic, so I gotta believe that ORs would make for a better query plan - unless the vast majority of the results are caught by the first query. It may be unavoidable, but likely the bigger problem is the LIKE operators.

  • lanmind (cs) in reply to planB
    planB:
    Nonody noticed the order by only has an efect on the last select of the unions. i guess that's not the effect the developer was going for

    Not on SQL Server:

    SELECT Field01 = 1
    UNION
    SELECT 2
    UNION
    SELECT 0
    UNION
    SELECT 4
    ORDER BY Field01
    
    Field01
    0
    1
    2
    4
    
  • Ralph (unregistered)

    Most databases have these things called query optimizers these days. Writing an arcane overly complex query to make the computer's work easier is premature optimization, like trying to outsmart your compiler. Don't forget that 99.9% of the ongoing costs are developer maintenance time, not CPU time.

    Oh, this is MS SQL?

    Never mind.

  • Bob (unregistered) in reply to Larry
    Larry:
    The problem with regexen is a lot like the problem with library functions: you can never be entirely sure what they're doing. So, in cases like this where the results are important, it is safest to write your own.

    Ha!

  • n9ds (cs) in reply to Larry

    "The problem with regexen is a lot like the problem with library functions: you can never be entirely sure what they're doing. So, in cases like this where the results are important, it is safest to write your own. "

    That sounds like the "Not Invented Here" argument to me.

  • Cantabrigian (cs)

    "regex scares me a little, OK, alot actually"

    Aaaaargh! It's "a lot" - two words. You wouldn't write "afew", would you? Then again, it's probably better than writing "allot" (when meaning "a lot", not "share out").

  • Peteris (unregistered)

    The OR solution would have different results in cases where a record matches multiple search criteria - in that case, the current solution would include duplicate rows.

    I'm not entirely sure why returning duplicate rows would be desired, but that's a different WTF.

  • Quango (cs) in reply to Larry
    Larry:
    The problem with regexe is a lot like the problem with library functions: you can never be entirely sure what they're doing. So, in cases like this where the results are important, it is safest to write your own.

    So by this logic the entire application framework and operating system would have to be replaced. And the hardware, and the drivers.

    Or you could write some unit tests on the regex expression that validate what it's doing.

  • MySQL geek (unregistered)

    Actually, here UNION is the same as OR, but in the MySQL point of view, presents a better performance ;)

  • @Deprecated (cs) in reply to Larry
    Larry:
    The problem with regexen is a lot like the problem with library functions: you can never be entirely sure what they're doing. So, in cases like this where the results are important, it is safest to write your own.

    In many cases it is safest NOT to write your own! EG., encryption. Or did I just win a "whooosh"?

    Did he really have to use charAt for two linear ranges? I think that if (c >= 'a' && c <= 'z') is less error-prone than "abcdefghijklmnpqrstuvwxyz".chartAt(c) != -1 Quick, spot the error!

  • Brillant (unregistered)

    TRWTF is to say that regular expressions are tidy and save processing power :-)))

  • TGV (cs) in reply to Larry
    Larry:
    The problem with regexen is a lot like the problem with library functions: you can never be entirely sure what they're doing. So, in cases like this where the results are important, it is safest to write your own.
    Since you write "regexen", as in one VAX, two VAXen, I'm assuming you're trolling. Congratulations!
  • Mike Woodhouse (unregistered)

    Need also to fix incorrect use of non-existent words.

    http://www.grammar-monster.com/easily_confused/alot_a_lot_allot.htm

  • anonymouse (unregistered) in reply to Larry
    Larry:
    The problem with regexen is a lot like the problem with library functions: you can never be entirely sure what they're doing. So, in cases like this where the results are important, it is safest to write your own.
    10/10 would rage again
  • the beholder (unregistered) in reply to @Deprecated
    @Deprecated:

    In many cases it is safest NOT to write your own! EG., encryption. Or did I just win a "whooosh"?

    I'm pretty sure you did. Congratulations!
    @Deprecated:
    Did he really have to use charAt for two linear ranges? I think that if (c >= 'a' && c <= 'z')="" is="" less="" error-prone="" than="" "abcdefghijklmnpqrstuvwxyz".chartat(c)="" !="-1" quick,="" spot="" the="" error!=""></=>
    You mean other than the absence of 'o', or the fact the original did account for uppercase letters while you didn't bother going that far?
  • mozbo (cs)

    Dave's not here, man.

  • Larry (unregistered) in reply to Quango
    Quango:
    Larry:
    The problem with regexe is a lot like the problem with library functions: you can never be entirely sure what they're doing. So, in cases like this where the results are important, it is safest to write your own.

    So by this logic the entire application framework and operating system would have to be replaced. And the hardware, and the drivers.

    Well frankly I've never cared for the leading OS options all that much, so yeah. And drivers, aren't they the things that create fatal crashes all the time?

    As for hardware, I suppose you're still buying yours from China? Hmmm?

    If you're in a situation where results matter, safest bet is to make your own. If you want it done right, do it yourself.

    You know how free trade is always destroying local economies? Buy from your own town, not online? Well get more local. Only trade with people on your own block. In your own house. Your own bedroom. See where this is going?

  • Herr Otto Flick (unregistered)

    TRWTF is Whitesmiths braces, amiright. Allman or bust, that's what I say.

  • Bernie The Bernie (unregistered)

    How does it come that you do not know what's the num variable for? Has following function been deleted:

    function checkNum(sStr)
    {
    var alpha = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
    var num   = '0123456789';
    var Char;
    var isNum = true; 
    for (var i=0;(i<sstr.length) &&="" (isnum="=true);i++)" {="" char="sStr.charAt(i);" if="" (num.indexof(char)="=-1)" {="" isnum="false;" }="" }="" return="" isnum;="" }="" end=""></sstr.length)>

    Please add it back to the code base!

  • Jack (unregistered) in reply to Quango
    Quango:
    So by this logic the entire application framework and operating system would have to be replaced. And the hardware, and the drivers.
    True story: My first computer was from Atari, and I had to write my own modem driver and printer driver. I even separated the print formatting commands from the document formatting codes so that I could buy a different printer someday and not have to modify all my documents.

    At least it came with a disk driver. But I had to add a layer on top of that so that a single file could be larger than a whole floppy disk.

    It's not that hard. You can do it if you want.

  • Cyberzombie (unregistered) in reply to Larry

    "^\w*$"

    Simple enough.

  • Captcha:sino (unregistered)
  • Tom (unregistered) in reply to Cyberzombie
    Cyberzombie:
    "^\w*$"

    Simple enough.

    What if you're using a language where $" is a built-in variable, and double-quoted strings interpolate $Vars? Oh, and newline doesn't necessarily mean end of statement?

    It's never as simple as it looks.

  • Delve (cs) in reply to Larry

    Because there will be a time when it's a good idea to write more code for simple tasks that have been done a million times over like confirming a string is composed only of the basic Latin alphabet.

    When results are important you go with what works rather than ginning up your own solutions with all the inherent human error that new code implies.

  • Cyberzombie (unregistered) in reply to Tom
    Tom:
    Cyberzombie:
    "^\w*$"

    Simple enough.

    What if you're using a language where $" is a built-in variable, and double-quoted strings interpolate $Vars? Oh, and newline doesn't necessarily mean end of statement?

    It's never as simple as it looks.

    If somebody knows how to use a regex, then they better know how to program in that language - though this is TDWTF...so ignore what I typed :)

  • DCRoss (cs) in reply to Tom
    Tom:
    Cyberzombie:
    "^\w*$"

    Simple enough.

    What if you're using a language where $" is a built-in variable, and double-quoted strings interpolate $Vars? Oh, and newline doesn't necessarily mean end of statement?

    It's never as simple as it looks.

    And what if your compiler only produces eight bit code and both of your legs are broken? Then how would you solve the problem?

  • chris (unregistered) in reply to Peteris
    Peteris:
    The OR solution would have different results in cases where a record matches multiple search criteria - in that case, the current solution would include duplicate rows.
    I don't think it would. Assuming that SQL Server and the w3schools page I just read follow standard practice, UNION ALL concatenates the results of the queries, including duplicates, but UNION returns a unique set.
  • Geoff (unregistered) in reply to Quosek

    That is problem with query optimize though. If your application needs the performance right now okay, sometimes you have to code around the ugly. In general though I'd say if your database is not stressed and performance is alright, I'd rather right clean code, at least when it ought to be possible for an optimizer to deal with well, than stick in some ugly workaround.

    If you have to use multiple selects and UNION to get reasonable execution plans for simple OR conditions, the problem is your database software.

  • Leander (unregistered)

    String searchString="select * from ProjectAndTask_view"; if (searchWhere !=""){ searchString=searchString + " where ProjectCode like '" + searchWhere + "%' union " ; searchString=searchString + "select * from ProjectAndTask_view where ProjectDesc like '" + searchWhere + "%' union " ; searchString=searchString + "select * from ProjectAndTask_view where TaskCode like '" + searchWhere + "%' union " ; searchString=searchString + "select * from ProjectAndTask_view where TaskDesc like '" + searchWhere + "%'" ; } searchString = searchString + " ORDER BY sortval";

    Actually, this is very possible. I had todo a similar things for performance issues. A union sometimes will perform aster then combining multiple ORs.

    In my case though the query was created at runtime, and it could not be predicted at coding time. The ORsolution was sometimes fast, sometimes very slow. Using the UNION alternative was "not to slow, not to fast" (almost) all of the time.

  • me (unregistered) in reply to MySQL geek

    It is also faster in MSSQL

  • Neil (unregistered) in reply to Cyberzombie
    Cyberzombie:
    "^\w*$"

    Simple enough.

    1. Inside a double quoted string, \ is typically an escape character. Even if there is no special meaning for \w you will still lose the .

    1. Inside a regex, \w typically matches underscores too.
  • Geoff (unregistered) in reply to Brillant

    They usually do save processing over say a mess of split(),join(),mid$(),left$(),right$(),For i = 0 to len(str); if str[i] = .... EndFor

    stuff

  • Tristram (unregistered)

    TRWTF with the last one is using a boolean variable to indicate that it's time to break out of the loop, instead of using GOTO, like God intended.

  • Jim (unregistered) in reply to DCRoss
    DCRoss:
    And what if your compiler only produces eight bit code and both of your legs are broken? Then how would you solve the problem?
    I think at that point I'd have to interview at another employer, so thank you for your time.
  • Unicorn #2816 (unregistered) in reply to Tristram
    Tristram:
    goto TRWTF FIX: use GOTO, like God intended. goto DONE TRWTF: using a boolean variable to indicate that it's time to break out of the loop goto FIX DONE:
    FTFY
  • Frak (unregistered) in reply to Geoff
    Geoff:
    I'd rather right clean code
    and dirty English. Or did you left your brain home today?
  • Will (unregistered) in reply to DCRoss
    DCRoss:
    And what if your compiler only produces eight bit code
    If you're as good as you think you are, you ought to be able to get the complier to output the desired 16-bit instruction by tricking it into emitting two unrelated 8-bit instructions.
  • Steve The Cynic (cs) in reply to Frak
    Frak:
    Geoff:
    I'd rather right clean code
    and dirty English. Or did you left your brain home today?
    It's perfectly good English. To right something means to set it upright after it has fallen on one side (or even upside down). The RNLI (the UK's lifeboat-operating organisation, about the only UK charity I'd consider giving money to) has a stock of long-range shore-to-ship lifeboats that can right themselves.
  • Bob (unregistered) in reply to Will
    Will:
    DCRoss:
    And what if your compiler only produces eight bit code
    If you're as good as you think you are, you ought to be able to get the complier to output the desired 16-bit instruction by tricking it into emitting two unrelated 8-bit instructions.
    This could be automated. You could develop a table of those "unrelated 8-bit instructions" that produce the required 16 bit codes. Then, as you write what you want in 16-bit, this utility pulls together the table entries and assembles them for you.

    You could call it an assembler.

  • Yank (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Frak:
    Geoff:
    I'd rather right clean code
    and dirty English. Or did you left your brain home today?
    It's perfectly good English. To right something means to set it upright after it has fallen on one side (or even upside down). The RNLI (the UK's lifeboat-operating organisation, about the only UK charity I'd consider giving money to) has a stock of long-range shore-to-ship lifeboats that can right themselves.
    So you're one of those who likes to think the UK knows anything about good English?

Leave a comment on “The New TODO and More”

Log In or post as a guest

Replying to comment #:

« Return to Article