• Amateur Troll (unregistered) in reply to ted
    ted:
    Amateur Troll:
    It's a slow day at work...does anyone mind if I start a flame war?

    F**k you. You're not clever.

    I was hopping for something a little more original.

  • rfoxmich (unregistered)

    While 0 is actually quite a bit more subtle.. in an embedded platform with no memory management you can overwrite the constants.. just watch out for side-effects in the functions that conditionally redefine 0 to nonzero. That's why the code was compiled with optimization turned off ;-)

  • midas (unregistered) in reply to dohpaz42
    dohpaz42:
    trtrwtf:
    I don't think there's anything wrong with an early return - if your functions are too long to keep track of the returns, they're too long, period, and you need to break them up. This "construct", however, is basically an early return with an added level of obfuscation. Just return and be done with it, I say. Not to say there couldn't be cases where it's useful, but I can't think of any.

    Ugh. </facepalm>

    Early returns are TRWTF (and the devil). When debugging a function with N number of returns, you have to add N number of distinct breakpoints just to debug where a function call exits at; such a waste of time and resources. Come on, which would you rather debug:

    <?php
    function myFuncEarly($data) {
     global $some_other_data;
    
     if (empty($data))
        return false;
    
     if (!is_array($data))
        return false;
    
     if ($data != $some_other_data)
        return false;
    
     return true;
    }</pre>
    

    or

    <?php
    function myFuncLate($data) {
     global $some_other_data;
     $return = true;
     
     if (empty($data))
        $return = false;
    
     if (!is_array($data))
        $return = false;
    
     if ($data != $some_other_data)
        $return = false;
    
     return $return;
    }</pre>
    

    Both functions do the same thing, but in the former you would have to add 3x as many debugging breakpoints just to know why the function returned false. But, in the latter, you only have to add one debug breakpoint.

    Early returns are nothing more than lazy tools for unimaginative programmers.

    First, we were discussing which was best of:

    1. using goto
    2. using do {...break;...} while (false);
    3. using early return

    and your problem is a problem regardless.

    Second, your first example is IMO more readable.

    Third, in your second example, all three tests are executed regardless. In a slightly different example, the third test fails if any of the second two tests returns false. This would not affect your first example but would make the second example way more complex.

  • ted (unregistered) in reply to Amateur Troll
    Amateur Troll:
    ted:
    Amateur Troll:
    It's a slow day at work...does anyone mind if I start a flame war?

    F**k you. You're not clever.

    I was hopping for something a little more original.

    Oh, fuck me with a fork...

    You say you want to start a flame war, and then I help you out, but complain how it doing it?!?

    I don't see you doing any better, dicklicker. Maybe if you didn't spend all day with your daddy's cock in your mouth you'd have the brains to offer me something to flame in the first place, retard.

    YOU!!! FUCKING!!!! REATARRRDF!!!!!!!!!!!!!!!!@!!!@

    Captcha: consequat - You pissed me off, consequatally, I got pissed

  • trtrwtf (unregistered) in reply to dohpaz42
    dohpaz42:
    Ugh. </facepalm>

    Come on, which would you rather debug:

    Neither. They're PHP. I'd rather remove my left eye with a runcible spoon.

    However, in this case there's no debugger needed. There are three cases in which you can get a false return value. If you get an unexpected false, you need to debug your data, not this function.

    Early returns are nothing more than lazy tools for unimaginative programmers.

    Early returns prevent confusion: you do your thing and get out. (And brace your if blocks, bucko.)

  • Hortical (unregistered) in reply to midas
    midas:
    dohpaz42:
    Ugh. </facepalm>

    Early returns are TRWTF (and the devil). When debugging a function with N number of returns, you have to add N number of distinct breakpoints just to debug where a function call exits at; such a waste of time and resources. Come on, which would you rather debug:

    First, we were discussing which was best of:

    1. using goto
    2. using do {...break;...} while (false);
    3. using early return

    and your problem is a problem regardless.

    Second, your first example is IMO more readable.

    Third, in your second example, all three tests are executed regardless. In a slightly different example, the third test fails if any of the second two tests returns false. This would not affect your first example but would make the second example way more complex.

    But he doesn't have to double-click the beginning of as many lines! Do you know how much time that saves? What if the function is a thousand lines long and has dozens of early returns? You'll feel stupid when you try to debug that, let me tell you.

  • Hortical (unregistered) in reply to trtrwtf
    trtrwtf:
    ... Early returns prevent confusion: you do your thing and get out. (And brace your if blocks, bucko.)

    Oh, shit, I disagree with this one detail, therefore you suck and should never program again!

  • MasonicParrot (unregistered) in reply to HP PhaserJet
    HP PhaserJet:
    I wonder if this snippet of mine is going to piss anyone off:
    	public bool Read()
    	{
    		again:
    
    		if (!Reader.Read()) return false;
    
    		// Ignore whitespace and comments
    		if ((Reader.NodeType == XmlNodeType.Whitespace) ||
    			(Reader.NodeType == XmlNodeType.Comment))
    		{
    			goto again;
    		}
    
    		Reader.MoveToElement();
    		return true;
    	}

    It's got a goto and a conditional with a side-effect!

    Never had any problem debugging it, even when there were bugs. Never had any problem reading it.

    Doesn't piss me off, but then neither does do-while-false. In both cases, there's a small overhead in learning what it does but then you do and it's not a big problem.

    TRWTF is assuming that there's one 'true way' to do everything. Goto, do-while-false, early returns etc. is like everything else: another feather to your programming cap. Sometimes they're appropriate, sometimes they're not.

    And having the do-while-false on every single line of the application code (as purported in the article) is clearly not appropriate.

    Strange that no-one has mentioned using exceptions to achieve error handling. We're talking about C++ after all.

  • trtrwtf (unregistered) in reply to Hortical
    Hortical:
    But he doesn't have to double-click the beginning of as many lines! Do you know how much time that saves? What if the function is a thousand lines long and has dozens of early returns? You'll feel stupid when you try to debug that, let me tell you.

    I'll feel much better once I pay him a visit. I'll bring that runcible spoon. Debug the programmer, then debug the program, I always say.

  • XXXXX (unregistered) in reply to midas
    midas:
    dohpaz42:
    trtrwtf:
    I don't think there's anything wrong with an early return - if your functions are too long to keep track of the returns, they're too long, period, and you need to break them up. This "construct", however, is basically an early return with an added level of obfuscation. Just return and be done with it, I say. Not to say there couldn't be cases where it's useful, but I can't think of any.

    Ugh. </facepalm>

    Early returns are TRWTF (and the devil). When debugging a function with N number of returns, you have to add N number of distinct breakpoints just to debug where a function call exits at; such a waste of time and resources. Come on, which would you rather debug:

    <?php
    function myFuncEarly($data) {
     global $some_other_data;
    
     if (empty($data))
        return false;
    
     if (!is_array($data))
        return false;
    
     if ($data != $some_other_data)
        return false;
    
     return true;
    }</pre>
    

    or

    <?php
    function myFuncLate($data) {
     global $some_other_data;
     $return = true;
     
     if (empty($data))
        $return = false;
    
     if (!is_array($data))
        $return = false;
    
     if ($data != $some_other_data)
        $return = false;
    
     return $return;
    }</pre>
    

    Both functions do the same thing, but in the former you would have to add 3x as many debugging breakpoints just to know why the function returned false. But, in the latter, you only have to add one debug breakpoint.

    Early returns are nothing more than lazy tools for unimaginative programmers.

    First, we were discussing which was best of:

    1. using goto
    2. using do {...break;...} while (false);
    3. using early return

    and your problem is a problem regardless.

    Second, your first example is IMO more readable.

    Third, in your second example, all three tests are executed regardless. In a slightly different example, the third test fails if any of the second two tests returns false. This would not affect your first example but would make the second example way more complex.

    Furthermore, you still need three breakpoints. Just because it is false at the final return statement, you have no indication which of your 3 if/then tests hit.

    So what you are really looking for is a quad-state boolean: true, false, array, someOtherWTF

  • Anon (unregistered) in reply to XXXXX
    XXXXX:
    Furthermore, you still need three breakpoints. Just because it is false at the final return statement, you have no indication which of your 3 if/then tests hit.

    Just what I was thinking. Even with a single return, you're still going to have to back track to the assignments that would've been returns to figure out where the final value came from.

  • (cs) in reply to HP PhaserJet
    HP PhaserJet:
    I wonder if this snippet of mine is going to piss anyone off:
    public bool Read()
    	{
    		again:
    
    		if (!Reader.Read()) return false;
    
    		// Ignore whitespace and comments
    		if ((Reader.NodeType == XmlNodeType.Whitespace) ||
    			(Reader.NodeType == XmlNodeType.Comment))
    		{
    			goto again;
    		}
    
    		Reader.MoveToElement();
    		return true;
    	}

    It's got a goto and a conditional with a side-effect!

    Never had any problem debugging it, even when there were bugs. Never had any problem reading it.

    Yes, it pisses me off, when you could have done the below sans CodeSmell:

    public bool Read()
    {
       if (Reader.EOF) return false;
       while (Reader.Read()) 
       {
          if (Reader.NodeType != XmlNodeType.Whitespace && Reader.NodeType != XmlNodeType.Comment)
          {
             Reader.MoveToElement();
             return true;
          }
       }
    }

    Addendum (2011-07-11 13:24): forgot the return false at the end. My bad.

  • Frank (unregistered) in reply to Patryk Zawadzki

    That has been actually useful.

    I have log files from the screen program which have control codes (ANSI colors) which make less go into hex dump, but using cat file | less surpresses that so I can get normal output.

    That might be a WTF in itself (the misdetection and the fact it doesn't detect on a pipe).

  • Hp PhaserJet (unregistered) in reply to hoodaticus
    hoodaticus:
    HP PhaserJet:
    I wonder if this snippet of mine is going to piss anyone off:
    public bool Read()
    	{
    		again:
    
    		if (!Reader.Read()) return false;
    
    		// Ignore whitespace and comments
    		if ((Reader.NodeType == XmlNodeType.Whitespace) ||
    			(Reader.NodeType == XmlNodeType.Comment))
    		{
    			goto again;
    		}
    
    		Reader.MoveToElement();
    		return true;
    	}

    It's got a goto and a conditional with a side-effect!

    Never had any problem debugging it, even when there were bugs. Never had any problem reading it.

    Yes, it pisses me off, when you could have done the below sans CodeSmell:

    public bool Read()
    {
       if (Reader.EOF) return false;
       while (Reader.Read()) 
       {
          if (Reader.NodeType != XmlNodeType.Whitespace && Reader.NodeType != XmlNodeType.Comment)
          {
             Reader.MoveToElement();
             return true;
          }
       }
    }

    Addendum (2011-07-11 13:24): forgot the return false at the end. My bad.

    I like this better:

    public bool Read()
    {
       while (Reader.Read()) 
       {
          if (Reader.NodeType == XmlNodeType.Whitespace || 
              Reader.NodeType == XmlNodeType.Comment)
             continue;
    
          Reader.MoveToElement();
          return true;
       }
       
       return false;
    }

    It's for a small tool that was never used, so don't worry. Not that you'd have to work with it in any event.

  • (cs)

    This just looks like macro code that was migrated into non-macro code by a programmer that didn't understand why the macro code required a do {...} while (0) construct. Hardly the biggest offence in the world, and not what I would consider to be front page news.

    On the whole use-of-goto argument: I'll readily acknowledge that it has its time and its place, but that doesn't change that it's an antiquated, less-safe and mostly vestigial technique that breaks the compiler's ability to both optimize your code and to generate meaningful warnings.

    It doesn't help that most of the time I see it used by programmers today it's by either old-timers or juniors who like to liberally pepper it all over the place that modern control structures would work just as well, turning their code into spaghetti constructs that are a real pain to both comprehend and debug. These programmers typically write functions that sprawl for page-after-page in winding control structures with no sense of encapsulation, abstraction or information-hiding. Yeah, goto may not be evil in and of itself, but it's definitely one of evil's favourite tools.

  • (cs) in reply to Jerry
    Jerry:
    Severity One:
    Heisenberg is the one of the cat, right? That if a cat is in a closed box, you can't measure its velocity?
    Well almost. The smaller you make the box, the faster the cat is probably going. But you can never be entirely sure.
    Oh yes, I think I remember this one from school, but I'm not quite certain. It's called the "Heisenberg Faster Pussycat Principle", right?
  • Childish (unregistered) in reply to MasonicParrot
    MasonicParrot:
    gallier2:
    Yes, my colleague uses that construct, I hate him for that. It's completely retarded. If you conceptually need a goto (and an error exception is a good reason for a forward goto), do a goto. The break is a goto, it's not because it wears a mask, that it is not a goto. The worse about it, is that a break is for leaving a loop, but here you don't have a loop, so when you see do/break/while, you must considere 2 possibilities, is it or is it not a loop. My colleague even once used that thing, but made really a loop out of it by using a continue in one hidden case (reallocation of memory).

    Sounds like you should get your rage on with this guy:

    http://www.diag.com/news/DoWhileFalse.html

    Personally, I think it's a fine and useful idiom, no worse than an early return (cue the SESE brigade).

    This idiom should be replaced with the common switch statement. Just set the case options flag to each option. This makes the code much easier to follow.

    From the article...

         do {
    
              // Some really complicated code.
    
              if (bogus) {
    
                  rc = -1;
    
                  break;
    
              }
    
              // Some more really complicated code.
    
              if (giveup) {
    
                  rc = -2;
    
                  break;
    
              }
    
              // Yet more really complicated code.
    
              if (error) {
    
                  rc = -3;
    
                  break;
    
              }
    
         } while (false);
    

    ...becomes...

         switch (status) {
    
              // Some really complicated code.
    
              case bogus:
                  rc = -1;
                  break;
    
              // Some more really complicated code.
    
              case giveup:
                  rc = -2;
                  break;
    
              // Yet more really complicated code.
    
              case error:
                  rc = -3;
                  break;
         } /* end switch */
    
  • (cs) in reply to dohpaz42
    dohpaz42:
    Interactive debuggers are nothing more than lazy tools for unimaginative programmers.
    FTFY

    What? I can make sweeping generalizations too, can't I?

  • zunesis (unregistered) in reply to boog
    boog:
    dohpaz42:
    Interracial buggery is nothing more than a lazy tool for ugly programmers.
    FTFY

    Wha? I can lick swinging genitalia too, can't I?

    Fucked that for you?

  • (cs)

    Never attribute to incompetence that which can be described as malice.

  • zunesis (unregistered) in reply to hoodaticus
    hoodaticus:
    Yes (YES! YES!), it gets me off, when you have done the bellowed the CockSmell:
    public void ReadMyLips()
    {
       if (kyBottle.EOF) return;
       while (kyBottle.more()) 
       {
          if (holeType == HoleType.Mouth || holeType == HoleType.Anus)
          {
             Penis.MoveToHole();
             continue;
          }
       }
    }

    Addendum (2011-07-11 13:24): forgot to call you the morning after. My bad.

  • zunesis (unregistered) in reply to WthyrBendragon
    Whitering:
    Never attribute to impotence that which can be explained by your misshapen face, Ug-a-mug.
  • (cs) in reply to zunesis
    zunesis:
    hoodaticus:
    Yes (YES! YES!), it gets me off, when you have done the bellowed the CockSmell:
    public void ReadMyLips()
    {
       if (kyBottle.EOF) return;
       while (kyBottle.more()) 
       {
          if (holeType == HoleType.Mouth || holeType == HoleType.Anus)
          {
             Penis.MoveToHole();
             continue;
          }
       }
    }

    Addendum (2011-07-11 13:24): forgot to call you the morning after. My bad.

    You'll have to forgive Zunesis. He got assraped last night and left his brains all over a crusty towell on his bed.

  • zunesis (unregistered) in reply to hoodaticus
    hoodaticus:
    You'll have to fellate Zunesis. He got some asslovin' last night and left his man-milk all over a crusty towel on my bed. I'll re-hydrate it and mix it into a pie for us to eat later.

    You said you'd call, you bastard!

  • no u (unregistered)

    so... assuming that LOG_E_BREAK is for 'log error and break'.. why is it called twice?

    I'm guessing that the terror is much more complex than has been discussed so far

  • Wyrm (unregistered)

    Well, this kind of "loop" reminds me of a bit of code that went like this (yes, that's VB.NET, I know...):

    For i as Integer = 1 To 2 If i = 1 Then // Do something unrelated to i Else // Do something else unrelated to i End If Next

  • zunesis (unregistered) in reply to zunesis
    hoochiekiss:
    public void ReadMyLips()
    {
        you.EatADick();
    }
  • odor n (unregistered) in reply to Amateur Troll
    Amateur Troll:
    ted:
    Amateur Troll:
    It's a slow day at work...does anyone mind if I start a flame war?

    F**k you. You're not clever.

    I was hopping for something a little more original.
    Keep on hopping, Dennis.

  • Hortical (unregistered) in reply to zunesis
    zunesis:
    hoochiekiss:
    public void ReadMyLips()
    {
        ! new Phalluses()
    }
  • anonymous (unregistered) in reply to Joe Tennies
    Joe Tennies:
    Actually, my assumption is that it was originally a straight C program with that buried in the middle of a function somewhere. That is quite common in C as you can't declare a variable on the fly without a new scope being opened. That "int const nMatrices..." is why it was done.

    I don't program in old C.. but.. can you just created a new scope using {} brackets -without- a while loop?

  • (cs) in reply to Hortical
    Hortical:
    zunesis:
    hoochiekiss:
    public void ReadMyLips()
    {
        ! new Phalluses()
    }

    But the existing ones are fine?

  • zunesis (unregistered) in reply to C-Octothorpe
    C-Octopussy:
    Whortical:
    zunesis:
    hoochiekiss:
    public void ReadMyLips()
    {
        ! new Phalluses()
    }

    But the existing ones are fine?

    As if you have no opinion on the matter!

    For me, the is a distinction to be made on whether the phallus is attached to an (apparent) male or female.

    But surprises are still more than welcome!

  • sdfqsdqfsdfqsdfqsdf (unregistered) in reply to Frank
    Frank:
    That has been actually useful.

    I have log files from the screen program which have control codes (ANSI colors) which make less go into hex dump, but using cat file | less surpresses that so I can get normal output.

    That might be a WTF in itself (the misdetection and the fact it doesn't detect on a pipe).

    I suggest you try man less.

    In that look at '-r' and '-R'. Also read the commments it has. It's not a WTF. It's designed like that for a particular reason and you can chose to ignore that reason by using '-r'/'-R'.

  • gallier2 (unregistered) in reply to The Poop... of DOOM
    The Poop... of DOOM:
    gallier2:
    Sergey:
    do { } while(0) is a common idiom. The idea is that if you want to exit early on error, you just do a break and avoid a goto. And also if you want to put multiple statements in a macro.

    The break is a goto, it's not because it wears a mask, that it is not a goto.

    Everything is a goto. A loop isn't much more than: 10. // Shennanigans 11. yourvar++ 12. if (yourvar < iterations_amount) goto 10.

    A function call isn't much more than a masked goto label.

    Everything is a goto.

    Yes, but why do we not use them as goto then? Because it would be unreadable. The break masquerading as goto is less readable than a plain goto, in the case of the OP's code. It's hijacking a construct for another purpose. It's less readable, it gets really ugly if there are real loops (do break's & continue refer to the loop or to the pseudo-loop).

  • gallier2 (unregistered) in reply to dohpaz42
    dohpaz42:
    trtrwtf:
    I don't think there's anything wrong with an early return - if your functions are too long to keep track of the returns, they're too long, period, and you need to break them up. This "construct", however, is basically an early return with an added level of obfuscation. Just return and be done with it, I say. Not to say there couldn't be cases where it's useful, but I can't think of any.

    Ugh. </facepalm>

    Early returns are TRWTF (and the devil). When debugging a function with N number of returns, you have to add N number of distinct breakpoints just to debug where a function call exits at; such a waste of time and resources. Come on, which would you rather debug:

    <?php
    function myFuncEarly($data) {
     global $some_other_data;
    
     if (empty($data))
        return false;
    
     if (!is_array($data))
        return false;
    
     if ($data != $some_other_data)
        return false;
    
     return true;
    }</pre>
    

    or

    <?php
    function myFuncLate($data) {
     global $some_other_data;
     $return = true;
     
     if (empty($data))
        $return = false;
    
     if (!is_array($data))
        $return = false;
    
     if ($data != $some_other_data)
        $return = false;
    
     return $return;
    }</pre>
    

    Both functions do the same thing,

    No they don't. Your second version evaluates all condition regardless of their previous test.

    but in the former you would have to add 3x as many debugging breakpoints just to know why the function returned false. But, in the latter, you only have to add one debug breakpoint.

    Early returns are nothing more than lazy tools for unimaginative programmers.

    <?php
    function myFuncLate($data) {
     global $some_other_data;
    
     $return = !empty($data) && is_array($data) && $data == $some_other_data;
    }
    
    </pre>
    

    Here, corrected for you.

  • gnasher729 (unregistered) in reply to gallier2

    Quite a common pattern. Yes, if it was C, you would use a goto. It is C++. C++ hates gotos. You can't goto across a variable initialisation. Just compiling C code with gotos as C++ will very often produce errors. This construct lets you do gotos in C++ without compiler errors.

  • (cs) in reply to Hortical
    Hortical:
    dohpaz42:
    Ugh. </facepalm>

    Early returns are TRWTF (and the devil). When debugging a function with N number of returns, you have to add N number of distinct breakpoints just to debug where a function call exits at; such a waste of time and resources. Come on, which would you rather debug: ....

    Try setting a break point at the top of the function and stepping through it, once you've detected that there is a problem in that function?

    Are you kidding? By doing that he will lose all the emotion of debuging. If he puts the break at the beggining of the function, he'll simply see everything that the function does and find the missbehaving code somewhere... It is much better to jump all the code where the problem could be, that way he'll have something to think about.

  • FuBar (unregistered) in reply to WthyrBendragon
    WthyrBendragon:
    Never attribute to incompetence that which can be described as malice.
    For the youngsters here, the saying really goes: Never automatically attribute to malice what can adequately be explained by incompetence.
  • (cs)

    THEY'RE COMING TO TAKE [Paul] AWAY, HA, HA,,,,!!!

  • (cs) in reply to dkf
    dkf:
    It all depends on the definition of LOG_E_BREAK. If it's doing a unilateral test on errors, and printing a (low-value) message and doing a break if it's non-zero, it's just nasty. If it's doing anything else, it's time to page Mr. Lovecraft to take over its maintenance.

    LOL. Truly evil; truly evil!

  • sagaciter (unregistered) in reply to dogbrags
    dogbrags:
    Continuous Integration would have fixed the build issues. Good unit tests (including memory leak testing) would have handled the memory leak issues.

    And the logging, while not actually logging any useful message, are indeed useful -- I can look at the log file, and see the where the log statement is just before the program/thread died.

    I tend to agree. Sometimes, presenting the line number we were at when we died is more useful than something like:

    "ERROR - Something happened that wasn't meant to"

    or

    "ERROR - This should never happen"

    or even anything where the original programmer speculates on what the cause might have been. Aren't Error codes just simplified line numbers anyway?

    There's little more frustrating than an error message that suggests something is wrong that isn't...

  • a;we4gy (unregistered) in reply to Occasional Reader
    Occasional Reader:
    frits:
    Severity One:
    A Nonny Mouse:
    it's heisenberg's principle error logging: you can record the datetime of the error, or the error detail, but never both. making your response to the question "what went wrong?" of "i'm not sure" even more correct
    Heisenberg is the one of the cat, right? That if a cat is in a closed box, you can't measure its velocity?
    Nah, you're thinking of that kid that plays piano. I think his name is Schroeder.
    <pedant> Is he any relation to Schroedinger? </pedant>
    Obviously noone ever jokes on this site.
  • esse (unregistered) in reply to boog
    boog:
    The massive data allocation did cause a few raised eyebrows...
    Exactly how many eyebrows did Paul have?
    I thought we established a few weeks ago that 'few' might refer to 2
  • (cs) in reply to anonymous
    anonymous:
    I don't program in old C.. but.. can you just created a new scope using {} brackets -without- a while loop?
    Yes (well, I can't remember if that's true in old skool K&R, but that's really obsolescent now). However, if you're not doing a break or continue inside it, it's advised to use a do{…}while(0) instead since that has fewer syntactic nasties if used in a context where either a statement or block is expected (e.g., if or while body).
  • (cs) in reply to esse
    esse:
    boog:
    The massive data allocation did cause a few raised eyebrows...
    Exactly how many eyebrows did Paul have?
    I thought we established a few weeks ago that 'few' might refer to 2
    Plus it's always possible that Paul borrowed an extra eyebrow from the guy in the next cubicle. After all, the sentence never said that all the eyebrows were on the same person.
  • abico (unregistered) in reply to Amateur Troll
    Amateur Troll:
    It's a slow day at work...does anyone mind if I start a flame war?
    By all means - or you can simply join one of the normal ones here. I'll get you started...

    C-octo is a tool boog is a dick frits - still poking his nose in where it's not required Nagesh is an Indian pretending not to be a Westener pretending to be an Indian meep is peeping up again ted has anger management issues Captain Oblivious is oblivious to the fact that no-one finds him very funny java.lang.Chris - Java sucks dogs balls

    Some of these people are the same person, and the rest have puppets that regularly flood the forum. (I feel as though I may have missed someone obvious...)

  • jugis (unregistered) in reply to HP PhaserJet
    HP PhaserJet:
    MasonicParrot:
    Sounds like you should get your rage on with this guy:

    http://www.diag.com/news/DoWhileFalse.html

    Personally, I think it's a fine and useful idiom, no worse than an early return (cue the SESE brigade).

    The presence of the loop implies that there is a loop when there isn't. The presence of the goto shows there is a goto when there is.

    Ja, but ye can't be puttin' that goto in the macro in the dudes later example....

    I agree it's not clean, but I understand that it protects macros pretty good, wot?

    Of course, we could argue that macros should only be used for very simple stuff, otherwise we use these things called methods....but I'm sure a vast array of people here will yell at me for even sayin' that

  • (cs) in reply to esse
    esse:
    boog:
    The massive data allocation did cause a few raised eyebrows...
    Exactly how many eyebrows did Paul have?
    I thought we established a few weeks ago that 'few' might refer to 2
    Interesting, but a few points to consider:
    1. "Established" implies that we reached a consensus; I'm doubtful that such a thing has ever occurred on this site.
    2. If Paul has only two eyebrows (which I'd expect is quite typical among people named Paul), why use a vague term like "few"?
  • (cs) in reply to abico
    abico:
    Amateur Troll:
    It's a slow day at work...does anyone mind if I start a flame war?
    By all means - or you can simply join one of the normal ones here. I'll get you started...

    C-octo is a tool boog is a handsome dick frits - still poking his nose in where it's not required Nagesh is an Indian pretending not to be a Westener pretending to be an Indian meep is peeping up again ted has anger management issues Captain Oblivious is oblivious to the fact that no-one finds him very funny java.lang.Chris - Java sucks dogs balls

    Some of these people are the same person, and the rest have puppets that regularly flood the forum. (I feel as though I may have missed someone obvious...)

    FTFY

  • abico (unregistered) in reply to dohpaz42
    dohpaz42:
    trtrwtf:
    I don't think there's anything wrong with an early return - if your functions are too long to keep track of the returns, they're too long, period, and you need to break them up. This "construct", however, is basically an early return with an added level of obfuscation. Just return and be done with it, I say. Not to say there couldn't be cases where it's useful, but I can't think of any.

    Ugh. </facepalm>

    Early returns are TRWTF (and the devil). When debugging a function with N number of returns, you have to add N number of distinct breakpoints just to debug where a function call exits at; such a waste of time and resources. Come on, which would you rather debug:

    <?php
    function myFuncEarly($data) {
     global $some_other_data;
    
     if (empty($data))
        return false;
    
     if (!is_array($data))
        return false;
    
     if ($data != $some_other_data)
        return false;
    
     return true;
    }</pre>
    

    or

    <?php
    function myFuncLate($data) {
     global $some_other_data;
     $return = true;
     
     if (empty($data))
        $return = false;
    
     if (!is_array($data))
        $return = false;
    
     if ($data != $some_other_data)
        $return = false;
    
     return $return;
    }</pre>
    

    Both functions do the same thing, but in the former you would have to add 3x as many debugging breakpoints just to know why the function returned false. But, in the latter, you only have to add one debug breakpoint.

    Early returns are nothing more than lazy tools for unimaginative programmers.

    What if you had 10 if's instead of 3? As soon as the first is false, we needn't do the others - especially if they're methods that might themselves have issues....

    <not serious> I can see a while-switch paradigm coming on.... I assume here that php is much like c in syntax...
    $return = true;
    $checked = 0;
    while($return && ($checked < 3))
    {
      switch($checked)
      {
        case 0:
          $return = !empty($data);
          break;
        case 1:
          $return = is_array($data);
          break;
        case 2:
          $return = ($data == $some_other_data);
          break;
        default:
          break;
      }
      $checked++;
    }
    return $return;
    

Leave a comment on “The Legacy Handover”

Log In or post as a guest

Replying to comment #:

« Return to Article