• (unregistered)

    Perhaps he was being tongue-in-cheek with the "ingenious" comment....

    Then again, we don't give people the benefit of the doubt here.  :-)

  • (cs)

      Hey, those uppercase spaces can get you in a lot of trouble.     

  • (unregistered)

    Would uppercase whitespace be the written equivalent of deafening silence?

  • (cs)

    He's a genius! Especially because the title of his message box is "Message". Just, you know, in case there was some confusion from the user about whether or not they're looking at a message.

     

  • (unregistered) in reply to spooky action at a distance

    Slightly off topic but I'm just curious, let's say you need to trim and convert to lowercase, in what order should you implement? Trim first and then convert, or backwards? Or does it matter?  I mean if we're talking milliseconds of speed saved it might be worth it...my theory is better to trim first, then the ToLower() function would have fewer characters to scan and figure out how to turn to lower case.

  • (unregistered)

    DBox("The value of m_ingenious_module_variable is " + m_ingenious_module_variable + ".  Note: Be sure to _always_ set this to nothing.")

    Dude shoulda used a different delimiter token.  Perhaps something as ingenious as the two-character token "\n", for example?

  • (cs)

    What an 'ingenious' way to spell Text -- Tekst

  • (unregistered) in reply to
    :
    Trim first and then convert, or backwards?

    I think you're probably right that it is faster to trim first and then lowercase.

    To be sure, you would want to do a real benchmark test.  Just write two small functions and time how long it takes to run each one, in a loop for a million times.

    I did this using Perl and found it is faster to trim first, by a small fraction.  It depends on the amount of whitespace you have.  If the string is 1 character and 50 spaces, then you get a big boost.  If it's 50 characters and 1 space, it's a small boost.

    If you really wanted the fastest way, you would really want to do both the trim and lowercase at the same time.  Loop over each character, making each one lowercase, then when you see a space, check if that is the last space in the string, and trim the spaces off.  If you use two separate functions, it is going to take about twice as long.
  • (unregistered) in reply to RyGuy

    RyGuy:
    What an 'ingenious' way to spell Text -- Tekst

    I honestly thought it was some strange Hungarian notation or something that I just hadn't seen before.

    I also <FONT style="BACKGROUND-COLOR: #efefef">love the fact that by using the function he's effectively reduced his button options for textboxen to "Ok", and that's it.</FONT>

  • (unregistered) in reply to

    Tekst is dutch for text. Maybe he's dutch. We're not known for our leet programming skillzzz...

  • (unregistered)

    Ah, crap, I totally have to check all of my code... I've never accounted for lowercase spaces before.

  • (unregistered)

    The real WTF is that it is not even a function, it is a sub and can not return the modified text.

  • (unregistered)

    PETASCII (The character code from the Commodore PET,VIC, C64) had an uppercase space (character 160) typed as Shift-Space.  It looked the same, but was a different character.

    Maybe the coder was assuming the program would be ported to obsolete machines?

  • (cs) in reply to

    :
    The real WTF is that it is not even a function, it is a sub and can not return the modified text.

    I don't really agree with that, but:  An often overlooked fact that has probably caused lots of havoc over the years with VB6 programmers is that the default way to pass arguments to a function is by reference.  So if you call DBox(someVar) and then examine SomeVar when it returns, its value will have changed to reflect the substitution.

     

  • (cs)

    I'm surprised no one has commented on the silly pattern of

    <FONT face="Courier New">if condition {
        valid = true;
    }
    else {
        valid = false;
    }</FONT>

    which obviously can be expressed more succinctly as

    <FONT face="Courier New">valid = condition;</FONT>

  • (cs)

    err. some anonymouse guy said: maybe it would be faster to trim first then tolower second, hmmmmm. dont both those functions scan chars anyway, u not talking sense son.

  • (unregistered) in reply to

    Tekst does also mean text in Danish and Norwegian.

  • (unregistered) in reply to
    :
    :
    Trim first and then convert, or backwards?

    If you really wanted the fastest way, you would really want to do both the trim and lowercase at the same time.  Loop over each character, making each one lowercase, then when you see a space, check if that is the last space in the string, and trim the spaces off.  If you use two separate functions, it is going to take about twice as long.

    uh, i bet you didn't time that one, huh?

  • (unregistered) in reply to

    I caught that too.  With a little more effort, he could have created a list of parameters mirroring those of the MsgBox function and passed them along with the edited text.

  • (cs) in reply to

    :
    Tekst does also mean text in Danish and Norwegian.

    Maybe<FONT color=#000000> "ingenious" means something else in those languges? [:)]</FONT>

  • (cs) in reply to AndrewVos

    AndrewVos:
    err. some anonymouse guy said: maybe it would be faster to trim first then tolower second, hmmmmm. dont both those functions scan chars anyway, u not talking sense son.
    Yeah, but if the first scan removes characters, then the second scan will scan fewer characters, and will hence be faster. If you do it in the reverse order, you are guaranteed a full scan each time.

  • (cs) in reply to GWheeler
    GWheeler:

    I'm surprised no one has commented on the silly pattern of

    <font face="Courier New">if condition {
        valid = true;
    }
    else {
        valid = false;
    }</font>

    which obviously can be expressed more succinctly as

    <font face="Courier New">valid = condition;</font>



    You beat me to it.  This is a WTF that I see ALL THE TIME.
  • (unregistered) in reply to ftumph

    You want to know what I see all the time...

    if (string1.ToLower().Compare(string2.ToLower()) == 0)

    This is BOGUS. You are doing 2 allocations for every compare, which is insane. For the LOVE OF GOD, use string.Compare! (static method)

    if (string.Compare(string1, string2, true) == 0)

    The third parameter means "Case Insensitive". USE IT!!

  • (cs) in reply to
    :
    You want to know what I see all the time...

    if (string1.ToLower().Compare(string2.ToLower()) == 0)

    This is BOGUS. You are doing 2 allocations for every compare, which is insane. For the LOVE OF GOD, use string.Compare! (static method)

    if (string.Compare(string1, string2, true) == 0)

    The third parameter means "Case Insensitive". USE IT!!



    Or, assuming this is Java, use the String.compareToIgnoreCase() method.
  • (cs) in reply to Cthulhon
    Cthulhon:
    [image]  wrote:
    You want to know what I see all the time...

    if (string1.ToLower().Compare(string2.ToLower()) == 0)

    This is BOGUS. You are doing 2 allocations for every compare, which is insane. For the LOVE OF GOD, use string.Compare! (static method)

    if (string.Compare(string1, string2, true) == 0)

    The third parameter means "Case Insensitive". USE IT!!



    Or, assuming this is Java, use the String.compareToIgnoreCase() method.
  • (unregistered)

    Assuming there's a lower and uppercase space, and trim just works with the uppercase one, won't the double trimming just choke on this:

    "[lowercase space][uppercase space][lowercase space]Some text"?

    Z

  • (cs) in reply to BradC
    BradC:

    [image] AndrewVos wrote:
    err. some anonymouse guy said: maybe it would be faster to trim first then tolower second, hmmmmm. dont both those functions scan chars anyway, u not talking sense son.
    Yeah, but if the first scan removes characters, then the second scan will scan fewer characters, and will hence be faster. If you do it in the reverse order, you are guaranteed a full scan each time.

    ok, well in some cases. but how u gonna know if there is more white space, otherwise its worthless.

  • (unregistered) in reply to AndrewVos
    AndrewVos:
    [image] BradC wrote:

    [image] AndrewVos wrote:
    err. some anonymouse guy said: maybe it would be faster to trim first then tolower second, hmmmmm. dont both those functions scan chars anyway, u not talking sense son.
    Yeah, but if the first scan removes characters, then the second scan will scan fewer characters, and will hence be faster. If you do it in the reverse order, you are guaranteed a full scan each time.

    ok, well in some cases. but how u gonna know if there is more white space, otherwise its worthless.

    hey andrew -- r u a cool hacker? 

  • (cs) in reply to ftumph

    Yes, but one day you'll probably want to breakpoint one of the conditions but not the other, and it always turns out to be the case that adding a conditional breakpoint makes the program run like a dog, so you'll change it to look like this anyway.

    Or, just as likely, you'll end up needing something to happen in one case but not the other, so again you'll have to change it to the longhand form.

    And once one or both of these has happened a few times, you end up writing it like that to start with out of habit.

  • (cs) in reply to GWheeler

    Gordon bloody bennett, what happened to the quote? And why can't I edit it? And why do the adverts keep blowing themselves up to the entire screen, disabling the back button in the process? Presumably this is some Firefox "problem"... IE-only sites, eh, how very 2001.

    Anyway, I'll try that one again.

    GWheeler:

    I'm surprised no one has commented on the silly pattern of

    <font face="Courier New">if condition {
        valid = true;
    }
    else {
        valid = false;
    }</font>

    which obviously can be expressed more succinctly as

    <font face="Courier New">valid = condition;</font>



    																Yes, but one day you'll probably want to breakpoint one of the
    

    conditions but not the other, and it always turns out to be the case that adding a conditional breakpoint makes the program run like a dog, so you'll change it to look like this anyway.


    Or, just as likely, you'll end up needing something to happen in one case but not the other, so again you'll have to change it to the longhand form.


    And once one or both of these has happened a few times, you end up writing it like that to start with out of habit.

  • (unregistered) in reply to AndrewVos

    AndrewVos:
    ok, well in some cases. but how u gonna know if there is more white space, otherwise its worthless.

    The code would have to look for all the white space, of course.  But this can be done by scanning the string only once.  Doing a trim and then a lowercase would be two full scans in many languages.

    Here is some Perl code (this is not the way I would normally write Perl):

    <FONT face="Courier New">sub trimAndLowercase
    {
       $_ = "UPPERCASE   WHITESPACE   ";</FONT>

    <FONT face="Courier New">   my @str = split //;
       my $lastSpace = @str;   # This will be the index of the last space counted backwards from the end</FONT>

    <FONT face="Courier New">   for(my $i = 0; $i < @str; $i++) {
          $str[$i] = lc $str[$i];   # convert to lowercase</FONT>

    <FONT face="Courier New">      if($str[$i] eq ' ') {
             if($lastSpace == @str) {
                $lastSpace = $i;   # this is the first space we have seen so far, remember this spot
             }
          }
          else {
             $lastSpace = @str;   # we saw a non-space, forget the index
          }
       }</FONT>

    <FONT face="Courier New">   for(my $i = $lastSpace; $i < @str; $i++) {
          $str[$i] = undef;  # wipe out all the spaces
       }</FONT>

    <FONT face="Courier New">   return join '', @str;
    }</FONT>

    <FONT face="Courier New">print trimAndLowercase(), "|\n";</FONT>

  • (cs)
    ftumph:
    [image] GWheeler wrote:

    I'm surprised no one has commented on the silly pattern of

    <FONT face="Courier New">if condition {
        valid = true;
    }
    else {
        valid = false;
    }</FONT>

    which obviously can be expressed more succinctly as

    <FONT face="Courier New">valid = condition;</FONT>



    You beat me to it.  This is a WTF that I see ALL THE TIME.

    valid =  (as_tableName.Trim().ToLower().Trim().Equals(ms_srcTable.Trim().ToLower().Trim()));

    Ugh.

    The WTF with the condition isn't the assignment of a true if a complex condition is true, its the fact that the Explaining Variable "valid" is meaningless.

    if (String.Compare(table,source,true)==0)
    {
      tableMatchesSource = true;
    }
    else
    {
      tableMatchesSource = false;
    }

    after reducing the condition to something sane, it starts to seem more sensible to just put it on one line.

    tableMatchesSource = (String.Compare(table,source,true)==0);

  • (cs)

    This is one of those cases where:

    • If you think you can do it in a semi-compiled language faster than the language's compiled runtime, you're wrong. If you think you can do it by calling C functions faster than an OS that uses well-tuned lowest-level code, you're wrong.
    • Your cleanest, most intuitive algorithm is probably an order of magnitude slower than code optimized for a cpu architecture at the machine code level. You must think messily and with a frightful proclivity to madness to truly understand instruction pipelining. Because much smarter people than you made your OS, runtime, or interpreter, it will probably be much closer to this native ideal. [That said, several consumer-level compilers have become much more advanced in recent years.]
    • The first fetch will take an age in cpu cycles, the second should be L1/L2 cached and execute in relatively little time.
    • If it matters in any way what order you do the toLower and trim, you're using the wrong algorithm and possibly the wrong language.
    • If you have to run 1000+ executions in a tight loop to register a slight difference, it doesn't matter in any way, the real work of the program will more than mask any percieved savings.
    • You need a profiler and a deep understanding of all the running code you never see, much more than a little high-level intuition.

    This is a great example of code monkeys who think they know a little about optimization waste too much time hacking at tiny problems and leave glaring ones that take real . Sit down with Knuth's Art of Programming, books on your OS and framework by the creators of each, and several advanced OS, server, and database design books, and then you will be competent to discuss optimization.

    Yay, you've stumbled on to another one of my pet peeves. Ja ne! ^_^
  • (unregistered) in reply to RyGuy
    > What an 'ingenious' way to spell Text -- Tekst

    It is Dutch for text. I'd guess the author is Dutch or Flemish.
  • (cs) in reply to ftumph
    ftumph:
    [image] GWheeler wrote:

    I'm surprised no one has commented on the silly pattern of

    <FONT face="Courier New">if condition {
        valid = true;
    }
    else {
        valid = false;
    }</FONT>

    which obviously can be expressed more succinctly as

    <FONT face="Courier New">valid = condition;</FONT>



    You beat me to it.  This is a WTF that I see ALL THE TIME.

    How is this a WTF? It's more explicit, and therefore, easier to understand and maintain. Using the original WTF as an example, compare the following:

    if (as_tableName.Trim().ToLower().Trim().Equals(ms_srcTable.Trim().ToLower().Trim()))
    {
      valid = true;
    }
    else
    {
      valid = false;
    }

    versus...

     

    valid = (as_tableName.Trim().ToLower().Trim().Equals(ms_srcTable.Trim().ToLower().Trim()))

    If you're unfamiliar with the code, which is the easier to understand and maintain? Obviously, the former is easier to make sense out of. 

    I see this all the time. Programmers who consider themselves brilliant for being able to compact code into as few lines as possible. But sometimes, the stuff that's spread across multiple lines is much easier for others to read and maintain. The performance hit of the if..else block versus the valid = condition block is neglible, so why not do it in the most readable way possible?

    Personally, 90% of what I've done as a programmer is maintaining and fixing the stuff written by other people. I'm more than happy to give up tiny performance gains in the service of having code that's readable.

     

  • (cs) in reply to spooky action at a distance
    spooky action at a distance:

    If you're unfamiliar with the code, which is the easier to understand and maintain? Obviously, the former is easier to make sense out of. 

    I see this all the time. Programmers who consider themselves brilliant for being able to compact code into as few lines as possible. But sometimes, the stuff that's spread across multiple lines is much easier for others to read and maintain. The performance hit of the if..else block versus the valid = condition block is neglible, so why not do it in the most readable way possible?

    Personally, 90% of what I've done as a programmer is maintaining and fixing the stuff written by other people. I'm more than happy to give up tiny performance gains in the service of having code that's readable.

     

    Hmm. I'll admit I've used both constructs. I'll use the single statement form if the condition is simple or easily understood. If the condition is complex, sometimes I'll break it up into multiple if... else if... branches to improve readability/debugging. In this case, I thought the condition was more than simple enough to qualify.

    BTW: I don't think there's any significant performance difference between the two forms. A competent compiler could optimize the if... form into the simple assignment.

  • (unregistered)

    <FONT face=Tahoma size=2>Surely </FONT>

    <FONT size=1>

    <FONT face=Tahoma size=2>(as_tableName.Trim().ToLower().Trim().ToUpper().Trim()).Trim();</FONT>

    <FONT face=Tahoma size=2>would be more efficient?</FONT>

    </FONT>
  • (cs)

    <font color="#d3d3d3"><font face="Georgia">Sarcasm to full power, Mr. Sulu... </font></font>

    As I am sure Bat will point out, if you were to write this in Scheme so that it reads the input as a series of symbols which you could accumulate into a list, then convert the list of symbols to a string, you would avoid the whitespace problem completely at no added cost (except for a few trivial things like punctuation and formatting...). Hey, if you've got a built-in parser just sorta sitting around like that, you might as well use it, right? [:D]

    <font size="2"><font face="Garamond"><font color="#d3d3d3">I have to admit that I don't know how serious Bat is. He certainly comes across as the sort of rabid Lisper who scares a lot of people away from the beauty that is lambda calculus, but around here I suspect trolling as a matter of course. Much as as genuinely love Scheme, I know that the chances of actually getting to work in it professionally are somewhat less than my chances of breaking the sound barrier on foot.  Fortunately, I'm a passable coder in  most major languages, even if I do tend to get turned around once in a while (it's a hazard for us Jack-of-all-trades types) and occasionally miss some crucial subtlety that a more specialized programmer would consider obvious (ditto). Also,  now that Python seems to be gaining popularity, I may have a chance of doing real work in a language that doesn't make me want to gouge my eyes out.  Wish me luck, folks.</font></font></font>

  • (cs) in reply to Schol-R-LEA

    <font face="Georgia">Heh heh heh... I'm not as rabid as all that.  I'm actually a language junkie -- I work regularly in PHP, Perl, XSLT, HTML, Delphi, elisp, DOS batch, bash shell script, C, and Lua, and less regularly in Prolog, C++, Scheme, JavaScript, and a bunch of little languages of my own devising.  I've seen C# and Python and wouldn't mind using them if  I had reason to; I've seen Java and consider it to be the COBOL of the noughties.  Like any fan, I'm half bigot and half evangelist (but I repeat myself...).  Sorry if I'm scaring anyone away from LISP, but it is pretty clearly the most powerful language in terms of its inherent language capabilities, and that kind of power is inherently scary, whatever I or anyone else might say.  Perl has the same problem in a different way -- and both LISP and Perl gain a lot of their power from their idiosyncratic syntax, which is also what scares people...

    All of which means: he should have done it in LISP, dammit!  Or JavaScript!  Or -- no, wait! -- Intercal!

    </font>

  • (cs)

    Fair enough. It's always good to hear from another Lisp fan - it can seem awfully lonely at times.

  • (unregistered)

    Hello everybody, here's the author of the 'ingenious' piece of code. The ingenious part was indeed tongue-in-cheek. [:)]

    The problem was, I was making an Access Database for some company and Access just kills me with its limitations. So I wanted to make everything as fast for me as possible. I needed a lot of messageboxes with only OK buttons, so I made this. I never needed the _ character for the end user so it was a good choice.

  • (unregistered) in reply to

    :

    Assuming there's a lower and uppercase space, and trim just works with the
    uppercase one, won't the double trimming just choke on this:<br>

    "[lowercase space][uppercase space][lowercase space]Some text"?

    Z

    Nope, because the original code is myString.Trim().ToLower().Trim() it would remove the first space, convert the [uppercase space] to a [lowercase space] and then trim all the remaining space before Some text!

    A brilliant bit of coding there!  Full marks for redundancy.

  • (unregistered) in reply to
    :

    [image]  wrote:

    Assuming there's a lower and uppercase space, and trim just works with the
    uppercase one, won't the double trimming just choke on this:<br>

    "[lowercase space][uppercase space][lowercase space]Some text"?

    Z

    Nope, because the original code is myString.Trim().ToLower().Trim() it would remove the first space, convert the [uppercase space] to a [lowercase space] and then trim all the remaining space before Some text!

    A brilliant bit of coding there!  Full marks for redundancy.

    Actually, if Trim() only worked with uppercase spaces, the first space would never get trimmed and so neither would the ones after it! To trim a pattern like: [lowercase space][uppercase space][lowercase space][uppercase space]... (repeat n times) using this theoretical case sensitive Trim() function would require a loop :D

  • (unregistered) in reply to
    :

    Actually, if Trim() only worked with uppercase spaces, the first space would never get trimmed and so neither would the ones after it! To trim a pattern like: [lowercase space][uppercase space][lowercase space][uppercase space]... (repeat n times) using this theoretical case sensitive Trim() function would require a loop :D

    Hello, my name is Anonymous and I just wrote a WTF. One case conversion, followed by one trim would suffice. No loop.

  • (unregistered) in reply to

    Hi, My name is Anon E Mouse, and I just wrote a WTF.  <loud prolonged clapping>

    I didn't read the original post which said that trim only worked on Upper case spaces (which is a WTF all in itself)  So converting all upper case spaces to lower case spaces using the lower function would make it even worse, because now ALL the spaces would be left behind!

    That loop solution sounds good, but I can think of a better way.

    You need a recursive function which tests if the first character is a space (either upper or lower case).  If it IS a space, you call the function recursively, after first removing the leading space.  That removes all spaces from the front, but what about the end?

    To remove all the spaces at the end, you then reverse the string, and call that handy little recursive function again.  You take the result of that function, reverse it, and that is your trimmed String!  Ingenious eh?

    [8-)]

  • (unregistered) in reply to Cthulhon

    Hey, u dont know Java man. The method is equalsIgnoreCase(). Don't try to post comments about languages you are not familiar with.

  • (unregistered) in reply to GWheeler

    What do you think about this then. Which is the right way to do it?

    <FONT face="Courier New">//1
    if (condition)
    {
        //do some stuff</FONT><FONT face="Courier New">
        valid = true;
    }
    else
    {
        valid = false;
    }</FONT>

    <FONT face="Courier New">//2
    if (condition)
    {
        //do some stuff<FONT face="Courier New">
    }
    valid = condition;</FONT></FONT>

    //3
    <FONT face="Courier New">valid = condition;</FONT>
    <FONT face="Courier New">if (valid)
    {
        //do some stuff
    }</FONT>

    <FONT face="Courier New">/Erik</FONT>

  • (cs) in reply to foxyshadis
    foxyshadis:
    This is one of those cases where:
    • If you think you can do it in a semi-compiled language faster than the language's compiled runtime, you're wrong. If you think you can do it by calling C functions faster than an OS that uses well-tuned lowest-level code, you're wrong.
    • Your cleanest, most intuitive algorithm is probably an order of magnitude slower than code optimized for a cpu architecture at the machine code level. You must think messily and with a frightful proclivity to madness to truly understand instruction pipelining. Because much smarter people than you made your OS, runtime, or interpreter, it will probably be much closer to this native ideal. [That said, several consumer-level compilers have become much more advanced in recent years.]
    • The first fetch will take an age in cpu cycles, the second should be L1/L2 cached and execute in relatively little time.
    • If it matters in any way what order you do the toLower and trim, you're using the wrong algorithm and possibly the wrong language.
    • If you have to run 1000+ executions in a tight loop to register a slight difference, it doesn't matter in any way, the real work of the program will more than mask any percieved savings.
    • You need a profiler and a deep understanding of all the running code you never see, much more than a little high-level intuition.

    This is a great example of code monkeys who think they know a little about optimization waste too much time hacking at tiny problems and leave glaring ones that take real . Sit down with Knuth's Art of Programming, books on your OS and framework by the creators of each, and several advanced OS, server, and database design books, and then you will be competent to discuss optimization.

    Yay, you've stumbled on to another one of my pet peeves. Ja ne! ^_^

    I have to agree mostly, but on your first point, you would be amazed what some JIT's manage to get out of certain situations - in some (very limited) cases (synthetic math benches), interpreted languages which are executed by an interpreter with a builtin JIT can be a lot faster. Startup times are a lot slower, but once it's running it can be amazing (didn't believe it myself the first time I saw it). Anyway, currently the performance hit is usually IO-operations (network/disk/...) or a database engine. It's rare that it's CPU limited in real-world applications, memory limit is still a possibility, but CPU? Only if you do extremely stupid things. And if they would be CPU-limited and required to run in real-time, a good analisys shows that it will be, and that should not be written in an interpreted language. If it's some batch-processing afterwards, who cares that it will take 10 mins longer, if that makes the code more maintainable, when i.e. the rest of the project is also written in that same interpreted language.

    Anyway, the Java or C# piece of crap that was posted here is the other way around. It's just making execution slower with no reason, while nog making the code more maintainable or readable, which is BAD. This piece of code creates 6 objects for a stupid compare, which are left for the garbage collector afterwards. If such practices are used all over a project - you will certainly feel the performance impact.

    The other part, about the newlines, well - long live '\n' - how ingenious [:D]

  • (unregistered) in reply to KoFFiE
    Surely this is the best way to deal with conditions?

    [code language="c#"]boolean valid;
    if (condition)
    {
    valid = true;
    }
    else
    {
    valid = false;
    }

    if (!valid)
    {
    return false;
    }
    else
    {
    return true;
    }[/code]
    And what's wrong with this bloody forum software?
  • (cs) in reply to
    :

    What do you think about this then. Which is the right way to do it?

    <FONT face="Courier New">//1
    if (condition)
    {
        //do some stuff</FONT><FONT face="Courier New">
        valid = true;
    }
    else
    {
        valid = false;
    }</FONT>

    <FONT face="Courier New">//2
    if (condition)
    {
        //do some stuff<FONT face="Courier New">
    }
    valid = condition;</FONT></FONT>

    //3
    <FONT face="Courier New">valid = condition;</FONT>
    <FONT face="Courier New">if (valid)
    {
        //do some stuff
    }</FONT>

    <FONT face="Courier New">/Erik</FONT>

    You left one out -

    if(valid=condition)

    {

    //do some stuff (and please ignore the double spacing)

    }

    That will work in most languages, but it's best to avoid doing an assignment in a conditional for readability reasons.  The one time I use that structure is when I'm looping through a result set from a database query in PHP.

    I said most languages, because I believe Microsoft has made it impossible to do an assignment inside a conditional in C# to avoid those annoying, difficult to track down bugs where you use = instead of ==.

Leave a comment on “The Ingenious DBox with the Double Trim”

Log In or post as a guest

Replying to comment #:

« Return to Article