• (cs) in reply to Nand
    Nand:
    emurphy:


    Is there a good reason to avoid the following, which reads more like normal English?

    private boolean isAdministrator(String authCode)
    {
        return authCode.equals("01");
    }

    private boolean isFurniture(String productCode)
    {
        return productCode.equals("004") || productCode.equals("005");
    }



    Yes. That code will throw a NullPointerException when productCode == null. You'd have to check that first, or assume that it never happens and pray.




    "01".equals(authCode);

    "004".equals(productCode) || "005".equals(productCode);
  • (cs) in reply to Rusty B
    Anonymous:

     I wonder how they will handle the 'Case Else' ....



    Easy!

    /**
     * Method isDefault.
     * @param authCode
     * @return boolean
     */
    private boolean isDefault(String authCode)
    {
        if (!(is01(authCode) || is02(authCode) || is004or005(authCode) || is03or09or10(authCode))) return true;
        else return false;
    }
  • (cs) in reply to anon

    Anonymous:
    So is he also 'training' the developers to cram as much code onto one line as possible and to avoid the use of constants?

    Yeah, we all know they shouldn't include magic numbers in thier code!  Jeez...

  • (cs) in reply to rob_squared
    rob_squared:
    DWalker59:
    MikeMontana:
    Yeah, april fools. Too rediculous to be beleived - unless this is the output of some CodeWizard Tool.
     
    Why do so many people have trouble spelling "ridiculous"???


    Because people say it like they say words like redone remade and think an e belongs there.  Now its obviously wrong, because I've never heard of someone diculizing someone.

    I saw it in a movie I downloaded one time.
  • Anon (unregistered) in reply to bovilexic

    I actually really like the performance metric comment, I might start doing that in my code.  In a teaching environment it at the very least ensures that students are thinking about performance as they code.

    As for handling every single condition, I know a lot of professional programmers who swear by that practice.  It only has to save you time once to make the extra typing worth it.

    I think the real wtf are stuck up students who think they know more than their professors.  You don't.

  • (cs) in reply to kipthegreat

    Our company best practices says a method should have only one "return" statement.  Also says braces should enclose even one line of conditional code. Based on that we would code it as:

    string retVal = b;
    if (cond)
    {
        retVal = a;
    }
    return retVal;

    In the case of just two items like this, though, it does make more sense to use:

    return (cond) ? a : b;

    But for the code in the first post above, I'd get rid of the functions and use switch case.

  • (cs) in reply to E
    Anonymous:

    Or, instead of:

    if(condition) return true; else return false;

    How about:

    return condition;

    No, that's not self-documenting enough. It must instead read:

    if ( true == condition ) return true;
    else return false;
  • village idiot (unregistered)

    Is it just me.. or are they also violating the multiple return line law? I mean.. isn't it known from low level college courses that you should only have one return statement in a functions.. which is to simply set a variable equal to true or false.. Just a thought.

  • asdf (unregistered) in reply to village idiot
    Anonymous:
    Is it just me.. or are they also violating the multiple return line law? I mean.. isn't it known from low level college courses that you should only have one return statement in a functions.. which is to simply set a variable equal to true or false.. Just a thought.

    Perhaps, if your teacher is Niklaus Wirth. C programmers know better.

  • (cs) in reply to Anon

    I too gotta side with the professor. In school you study things that are rarely used in the real world because they are important to know even though you rarely touch them.

    So your classes should spend a lot of time on big-O notation to ensure you know it. You will go years between thinking about it in the real world, but when you need it you need it.

    As for the handle every case, often the most important comments are the ones that explain WHY some case isn't handled. Too often I have come into code I didn't write, and saw a few if statements that was obviously missing something (either because other parts of the code handled it, or because I knew something about the problem), and wondered if this was a bug or not.

    Though I would mark down any comment of the form "handle up to 10, including 0". I can see that from the if clause. (Though this isn't near as bad as the once common x = x+ 1; // add 1 to x comments that you see once in a while)

    Comments need to tell me why the code is doing something - I can see what it is doing.

  • (cs) in reply to DWalker59
    DWalker59:
    MikeMontana:
    Yeah, april fools. Too rediculous to be beleived - unless this is the output of some CodeWizard Tool.
     
    Why do so many people have trouble spelling "ridiculous"???

    Don't forget 'believed'...

  • noVum (unregistered) in reply to village idiot
    Anonymous:
    Is it just me.. or are they also violating the multiple return line law? I mean.. isn't it known from low level college courses that you should only have one return statement in a functions.. which is to simply set a variable equal to true or false.. Just a thought.

    Yeah. Use a goto to the end of the function and set a return variable instead. WTF...
  • Martin (unregistered) in reply to village idiot
    Anonymous:
    Is it just me.. or are they also violating the multiple return line law? I mean.. isn't it known from low level college courses that you should only have one return statement in a functions.. which is to simply set a variable equal to true or false.. Just a thought.


    Off course you are UTTERLY and COMPLETELY right!!!!!
    And NO! C programmers does not know better. They know worse! I make a living from cleaning up after you guys!
    Maybe some C programmer can keep track of his logic, but in the brand new world of teamwork, this just isn't good enough.

    The *only* right way to do this is:
    bool ReturnBool = false; // or true depending of your default
    if (something) {
        ...snip...
        ReturnBool = true;
        ...snip...
    }
    ...snip ...
    return ReturnBool;

    The very strange replies to this post tells me that the story is true. What they do is innocent in comparison to the WTF's in many of the reply's.

    To the browser-folks: I use FF and I can't copy/paste to the forum SW. If I could it would be a major security flaw, which is probably why it works in IE. I wote for new forum SW!
    Maybe that would also fix the WTF with the CAPTCH, that just failed again...
  • steve anon (unregistered) in reply to emurphy

    Your suggestion makes perfect sense to me.

    There are two good reasons to make a method:

      1) Create a useful abstraction.

      2) Simply make your code concise.

    The WTF code arguably accomplishes #2 (let's give them the benefit of the doubt that they use the same functions multiple times), but it, as you say, stops short..

    Good code accomplishes #1.

    Sometimes a crufty language forces you to make really weak abstractions to accomplish #2.  On the other hand, some languages alreadly express "in-ness."

    if productCode in ('02', '04):

        print 'Furniture'

    In a language like the above (Python), I would be somewhat cautious about creating an unnecessary level of indirection to replace a language idiom.  There might be reasons to do it--there might be several places where I need to map '02'/'04' to furniture--but I'd give it some consideration, and you might not choose to extract to methods.  Instead, you might have something like this:

    FURNITURE_CODES = ('02', '04')

    Then, I'd be able to tolerate code like this:

    if productCode in FURNITURE_CODES:

        print 'Polish'

    And then elsewhere:

    if productCode in FURNITURE_CODES:

        prices = FURNITURE_PRICE

     

     

     

     

     

     

     

     

     

  • Paul Theodorou (unregistered) in reply to Digitalbath
    Digitalbath:
    mrprogguy:

    Can someone please tell  me where that

    <font face="Courier New">if(condition) return something; else return somethingElse;</font>

    idiom came from?

    Why would you need to protect a <font face="Courier New">return</font> with an <font face="Courier New">else</font>?  If the return is exercised, then the other clause is ignored! 

    It's even in the original K&R book on C, written by the guys themselves, and it's no less idiotic coming from someone "authoritative."

    That, to me, is a serious WTF.

    This would be much better:

    private boolean is01(String authCode)
    {
      boolean returnboolean = false;

      if ("01".equals(authCode) == true) {

        returnboolean = true;

        return <font color="#000000">returnboolean</font>;

      }
     else if ("01".equals(authCode) == false) {

        returnboolean = false;

        return <font color="#000000">returnboolean;</font>

     else {

        returnboolean = false;

        return <font color="#000000">returnboolean;</font>

    <font color="#000000">   }</font>

    <font color="#000000">  //and just to make sure, ie FileNotFound case </font>

    <font color="#000000">  return returnboolean;
    }</font>

    <font color="#000000">//end joke</font>



    Seriously though...why not a case/switch statement (depending on your language flavour...) with a return value set in each case and a single return at the end? Is it that hard?!?! :P
  • steve anon (unregistered) in reply to steve anon

    Sorry, I hit "reply," not quote, so my previous posting makes no sense out of context.

  • Anon (unregistered) in reply to An apprentice
    Anonymous:
    Alex Papadimoulis:
    /**
    * Method is01.
    * @param authCode
    * @return boolean
    */
    private boolean is01(String authCode)
    {
    if ("01".equals(authCode)) return true;
    else return false;
    }

    At least it's properly documented! I wouldn't know this method returns a boolean otherwise. And the name authCode is so self-explaining...



    That syntax is for javadoc, so that your autogenerated html documentation contains info about that method.  It is not intended for human eyes.  So no, if you were only reading the HTML docs, you wouldn't know it returned a boolean otherwise.
  • (cs) in reply to Anon

    Obviously, the solution is to overload IsTrue to handle this case.

    if(IsTrue(aSomething,"005")) { stuff; }
    elseif (IsTrue(aSomething,"01")) { otherstuff; }

    Bool2 IsTrue(String aBoolean,String aString) {
    if("01".equals(aString)) return is01(aBoolean);
    elseif ("005".equals(aString)) return is005or03(aBoolean);
    elseif ("03".equals(aString)) return is005or03(aBoolean);
    else return Bool2.FileNotFound;
    }

    Can't you guys see the obvious implications? It's genious! It'll revolutionize coding!


    Also lol at people who think Single Return is a law, not a recommendation to help some people keep track of their logic, that has caused as many wtfs as return spamming in its day.

  • (cs) in reply to davewalthall

    davewalthall:
    The idiom:
      if(cond) return a;
      else return b;
    comes from a very reasonable place.  It implies that b is being returned because cond was not true.  If you instead write:
      if(cond) return a;
      return b;
    it implies that you are returning b because that is the appropriate thing to do if you reach that point, and is unrelated to cond.  I strongly believe that when code layout and structure reflects the underlying logic, that is a good thing. 

    David

    PS An even stronger statement of the idiom is:
      return (cond ? a : b);


    I agree with the PS portion, because that's what I would have done, and my complaint about the idiom used a very weak, easy to type, example.

    So, riddle me this, Caped Crusader:

    <FONT face="Courier New">int junkFunc() {
      if(someCondition()) 
      {
        callThis();
        callThat();
        return theOther();
      }

      doThis();
      doThat();
      return whatEver();
    }</FONT>

    How is that latter return not indicating that this is the default choice (that is to say, what to do when someCondition() comes back false)?  If you say the code is not documenting, then I'll be disagreeing with you.   How would anyone's perception of it be clearer if it used

    <FONT face="Courier New">else { .... return whatEver(); }
    </FONT>
    which might well (and minimally) cause a compiler warning in less savvy compilers?  (Not to mention generating extra pointless CPU instructions.)

  • (cs)

    Reminds me too much of a co-worker's code...

    int iMustBe5;
    ...
    if(iMustBe5 != 5) {
      throw new Exception("...");
    }


    brilliant!

  • tyler (unregistered) in reply to oguk

    for those that think multiple return statements are for the devil here is some code for you to write neatly and in a manner that is easier to understand than the following:

    say you have functions conditionn that modify the value of x and return a boolean.

    if (condition1(x)) return true;
    if (condition2(x)) return false;
    if (condition3(x)) return true;
    return false;

    remember that the conditionals must be performed in order because they have side effects.  And I know that I'll get a bunch of flack for have side effects of functions but sometimes that really is the best way.

  • stevedave (unregistered) in reply to Anon
    Anonymous:
    Anonymous:
    Alex Papadimoulis:
    /**
    * Method is01.
    * @param authCode
    * @return boolean
    */
    private boolean is01(String authCode)
    {
    if ("01".equals(authCode)) return true;
    else return false;
    }

    At least it's properly documented! I wouldn't know this method returns a boolean otherwise. And the name authCode is so self-explaining...



    That syntax is for javadoc, so that your autogenerated html documentation contains info about that method.  It is not intended for human eyes.  So no, if you were only reading the HTML docs, you wouldn't know it returned a boolean otherwise.


    Actually you would know from looking at the javadoc what the return type was.  You're supposed to put something like "@return some description of what to expect", as opposed to "@return boolean some description of what to expect".  Since a function can only have one return type, javadoc is smart enough to figure that out.

    Likewise for @param, you only need to give the name of the parameter before the description, the tool can figure out the type of that parameter.  When types are specified for @return and @param, it actually makes the HTML javadoc a little more redundant to read.
  • [email protected] (unregistered) in reply to tyler
    Anonymous:
    for those that think multiple return statements are for the devil here is some code for you to write neatly and in a manner that is easier to understand than the following:

    say you have functions condition[n](x) that modify the value of x and return a boolean.

    if (condition1(x)) return true;
    if (condition2(x)) return false;
    if (condition3(x)) return true;
    return false;

    remember that the conditionals must be performed in order because they have side effects.  And I know that I'll get a bunch of flack for have side effects of functions but sometimes that really is the best way.


    Well this would work and is neat, but it could take a tad longer to understand I suppose.. but having side-effects is going to make it difficult to understand as is..

    return condition1(x) || !condition2(x) || condition3(x);


    PS:  Does the captcha work on the first try for anyone??
  • homo opera user (unregistered) in reply to kipthegreat
    kipthegreat:

    PS: homooperausersayswhat


    What?
  • awefwaefwfae (unregistered) in reply to homo opera user

    I'm not doing anything until I'm refactoring to the EXTREME!

  • no name (unregistered) in reply to [email protected]
    return condition1(x) || !condition2(x) || condition3(x);

    Did you test before you posted? Did you even try to evaluate that in your head first???

    WTF
  • bonfyre (unregistered) in reply to mrprogguy
    mrprogguy:

    davewalthall:
    The idiom:
      if(cond) return a;
      else return b;
    comes from a very reasonable place.  It implies that b is being returned because cond was not true.  If you instead write:
      if(cond) return a;
      return b;
    it implies that you are returning b because that is the appropriate thing to do if you reach that point, and is unrelated to cond.  I strongly believe that when code layout and structure reflects the underlying logic, that is a good thing. 

    David

    PS An even stronger statement of the idiom is:
      return (cond ? a : b);


    I agree with the PS portion, because that's what I would have done, and my complaint about the idiom used a very weak, easy to type, example.

    So, riddle me this, Caped Crusader:

    <FONT face="Courier New">int junkFunc() {
      if(someCondition()) 
      {
        callThis();
        callThat();
        return theOther();
      }

      doThis();
      doThat();
      return whatEver();
    }</FONT>

    How is that latter return not indicating that this is the default choice (that is to say, what to do when someCondition() comes back false)?  If you say the code is not documenting, then I'll be disagreeing with you.   How would anyone's perception of it be clearer if it used

    <FONT face="Courier New">else { .... return whatEver(); }
    </FONT>
    which might well (and minimally) cause a compiler warning in less savvy compilers?  (Not to mention generating extra pointless CPU instructions.)

    errr.... this is no difference in that situation whether there is the else block or not; the generated assembly would be the same.

  • John Hensley (unregistered) in reply to village idiot
    Anonymous:
    Is it just me.. or are they also violating the multiple return line law? I mean.. isn't it known from low level college courses that you should only have one return statement in a functions.. which is to simply set a variable equal to true or false.. Just a thought.

    The main reason for the single return "law" in C is to make sure you clean up memory, locks, handles, etc. before you leave a function.

    This, on the other hand, is Java code.

  • cb (unregistered) in reply to no name

    Please enlighten me?

  • EV (unregistered) in reply to oguk
    oguk:
    Reminds me too much of a co-worker's code...

    int iMustBe5;
    ...
    if(iMustBe5 != 5) {
      throw new Exception("...");
    }


    brilliant!


    Actually, this may be pretty useful to stop buffer overflows

    </sarcasm>
  • (cs) in reply to MikeMontana

    I'm sad to say that this is not generated code... and the variable names are really terrible here in this project:

    • bonClaJur
    • e2x2
    • sprlt
    • ...

    Hell, I don't even know what they mean and I doubt the internals do. They also have the tendency to abbreviate all the variables:

    • code becomes cod
    • table becomes tbl
    • ...

    Ps: I know what my name means in english, but remember: Respect De Cock!

  • Well-Known Representative (unregistered) in reply to mrprogguy
    mrprogguy:

    davewalthall:
    The idiom:
      if(cond) return a;
      else return b;
    comes from a very reasonable place.  It implies that b is being returned because cond was not true.  If you instead write:
      if(cond) return a;
      return b;
    it implies that you are returning b because that is the appropriate thing to do if you reach that point, and is unrelated to cond.  I strongly believe that when code layout and structure reflects the underlying logic, that is a good thing. 

    David

    PS An even stronger statement of the idiom is:
      return (cond ? a : b);


    I agree with the PS portion, because that's what I would have done, and my complaint about the idiom used a very weak, easy to type, example.

    So, riddle me this, Caped Crusader:

    <font face="Courier New">int junkFunc() {
      if(someCondition()) 
      {
        callThis();
        callThat();
        return theOther();
      }

      doThis();
      doThat();
      return whatEver();
    }</font>

    How is that latter return not indicating that this is the default choice (that is to say, what to do when someCondition() comes back false)?  If you say the code is not documenting, then I'll be disagreeing with you.   How would anyone's perception of it be clearer if it used

    <font face="Courier New">else { .... return whatEver(); }
    </font>
    which might well (and minimally) cause a compiler warning in less savvy compilers?  (Not to mention generating extra pointless CPU instructions.)



    For me, it depends on how many lines are in those conditionals. If there's enough stuff there, then when I come back and look at the (default) block that's not part of a conditional, then I won't remember it's a conditional since I can't see that from what's on the screen in front of me.

    On the other hand, I'll do the multi-return thing when I believe that I'll show both returns on one screen of code for years to come.

    CAPTCHA = postal! Yes, indeedy!
  • Esben (unregistered) in reply to emurphy
    emurphy:
    VGR:

    private boolean isAdministrator(String authCode)
    {
        return "01".equals(authCode);
    }

    private boolean isFurniture(String productCode)
    {
        return "004".equals(productCode) || "005".equals(productCode);
    }


    Is there a good reason to avoid the following, which reads more like normal English?

    private boolean isAdministrator(String authCode)
    {
        return authCode.equals("01");
    }

    private boolean isFurniture(String productCode)
    {
        return productCode.equals("004") || productCode.equals("005");
    }



    The reason for doing this is you can newer get a null pointer exception sence "004" always is a string but productCode could be null.

    /Esben

  • themuppeteer (unregistered) in reply to Coughptcha

    Coughptcha:
    reed:
    You are number six!
    I am not a number. I am a free man!

    I was actually waiting for this answer ;)

  • (cs) in reply to Coughptcha
    Coughptcha:
    reed:
    You are number six!
    I am not a number. I am a free man!

    Number five needs input!
  • Thomas Ammitzb&#248;ll-Bach (unregistered) in reply to John Bigboote
    John Bigboote:
    rob_squared:


     Now its obviously wrong, because I've never heard of someone diculizing someone.


    "Diculize" has actually made its way into the vernacular; it's when somebody passes out and you duct-tape them to the couch and draw on them with magic marker.


    Here is a slashdot reference to that:
    http://yro.slashdot.org/comments.pl?sid=165706&threshold=2&commentsort=3&mode=nested&cid=13823126
  • Anthony (unregistered) in reply to village idiot
    Anonymous:
    Is it just me.. or are they also violating the multiple return line law? I mean.. isn't it known from low level college courses that you should only have one return statement in a functions.. which is to simply set a variable equal to true or false.. Just a thought.


    Yes. But it isn't a law. Some people seem to think it's a good idea, others ask for evidence of this and get none. Not all college courses teach this particular habit. That's all it is, a habit.

    Sure you need to dealacate what youm allocate, but we have try..finally blocks and garbage collectors these days.
  • Thomas Ammitzb&#248;ll-Bach (unregistered) in reply to tyler
    Anonymous:
    for those that think multiple return statements are for the devil here is some code for you to write neatly and in a manner that is easier to understand than the following:

    say you have functions condition[n](x) that modify the value of x and return a boolean.

    if (condition1(x)) return true;
    if (condition2(x)) return false;
    if (condition3(x)) return true;
    return false;

    remember that the conditionals must be performed in order because they have side effects.  And I know that I'll get a bunch of flack for have side effects of functions but sometimes that really is the best way.


    bool retval;
    if (condition1(x)) {
      retval = true;
    } else if
    (condition2(x)) {
      retval = false;
    } else
    if (condition1(x)) {
      retval = true;
    } else {
      retval = false;
    }
    return retval;

  • TC (unregistered) in reply to Tyler
    Anonymous:
    I agree.  I like the style:
    if (condition) doStuff;

    instead of
    if (condition) {
        doStuff
    }


    So do I, as long as doStuff is short (in lines, not necessarily characters). I even do lots of evil things just to make things into one line, mostly for error handling, e.g.
    if (blah) { fprintf(...); exit(1); }

    However, I always use braces, so

    if (cond) { doStuff; }
    This makes it easier when you need to modify the code in the block, and more importantly, the } serves to tell you where the if block ends. Visual aids are very important (ever try debugging code that's not properly indented?).

    There's the odd exception to this, and that's when I have stuff like
    for (i=0;i<9;i++) for (j=0; ...) {
    my_sudoku_solving_rules;
    }
  • (cs) in reply to Thomas Ammitzb&#248;ll-Bach
    Anonymous:
    Anonymous:
    for those that think multiple return statements are for the devil here is some code for you to write neatly and in a manner that is easier to understand than the following:

    say you have functions condition[n](x) that modify the value of x and return a boolean.

    if (condition1(x)) return true;
    if (condition2(x)) return false;
    if (condition3(x)) return true;
    return false;

    remember that the conditionals must be performed in order because they have side effects.  And I know that I'll get a bunch of flack for have side effects of functions but sometimes that really is the best way.


    bool retval;
    if (condition1(x)) {
      retval = true;
    } else if
    (condition2(x)) {
      retval = false;
    } else
    if (condition1(x)) {
      retval = true;
    } else {
      retval = false;
    }
    return retval;



    That case should be avoided as well. It's "bad" to drag along values (retval.) The function should return as soon as it's done working.

    I think you should avoid getting into a place where you have to write code like that in the first place. When doing object-oriented programming, you should use polymorphism to abstract the situation.

    You want to simpy write: return object.getCondition(); Each object then merely needs to overload the getCondition() function with the apropriate check that is relevant to that instance.


  • (cs) in reply to kipthegreat
    kipthegreat:
    Volmarias:
    Gosh, I love the fact that I can't use any BBcode, or HTML tags, or anything like that, JUST BECAUSE I'M USING OPERA.


    Opera is for hippies, gays, and terrorists.  Use Firefox.  It's what the cool kids are using.


    dude. I use firefox. I am gay. You use firefox. Therefore you are gay.
    =P
  • (cs) in reply to Alun Jones
    Anonymous:

    davewalthall:

    PS An even stronger statement of the idiom is:
      return (cond ? a : b);

    Or, as I saw it in a few places while at Microsoft:

    return !!cond;

    Seriously.

    This idiom has its place in languages like C, which has no boolean type, and where all non-zero integers are true (or perl which has an even wider range of 'true' and 'false' values). Using !!cond ensures that the value you get back is strictly 0 or 1. This actual value may matter to the caller.

  • (cs) in reply to oguk

    oguk:
    Reminds me too much of a co-worker's code...

    int iMustBe5;
    ...
    if(iMustBe5 != 5) {
      throw new Exception("...");
    }


    brilliant!

    Indeed, it actually is a XOR-replacement!

    <FONT size=2>int iMustBe5 = 4;</FONT>

    <FONT size=2>if(expr1) iMustBe5++;</FONT>

    <FONT size=2>if(expr2) iMustBe5++;</FONT>

    <FONT size=2>if(iMustBe5 != 5){</FONT>

    <FONT size=2>  throw new Exception("Error #"+iMustBe5);</FONT>

    <FONT size=2>}</FONT>

    See? You even get a nice error code, makes you look really professional :-)

     

  • (cs) in reply to TDC

    How cool is that, the code actually had a smaller size than the rest in the editor. The real WTF is..

  • Gill Bates (unregistered) in reply to Alun Jones
    Anonymous:

    davewalthall:

    PS An even stronger statement of the idiom is:
      return (cond ? a : b);

    Or, as I saw it in a few places while at Microsoft:

    return !!cond;

    Seriously.



    Oh yes.... We are using a preprocessor for all of our soure code, and it cannot handle any special signs, like !@#
    So in order to use them we need to escape them...
    !! will thefore be substituted into !
    which the compiler then understands.....

    Brillant isn't it ??

    GB

    P.S. Yes, our press chief's name is indeed Paula. How could you have guessed ?

  • Master Rick (unregistered) in reply to DWalker59
    DWalker59:
    MikeMontana:
    Yeah, april fools. Too rediculous to be beleived - unless this is the output of some CodeWizard Tool.
     
    Why do so many people have trouble spelling "ridiculous"???


    That's not all this troll can't spell! the guy even struggled with one of the most basic spelling rules with: 'beleived'. I remember learning a rhyme about 'I before E except after C....' when I was about 6. Even my 4 year old sister whose first language is Czech, not English, can cope with that one!
  • (cs) in reply to kipthegreat

    kipthegreat:
    Volmarias:
    Gosh, I love the fact that I can't use any BBcode, or HTML tags, or anything like that, JUST BECAUSE I'M USING OPERA.


    Opera is for hippies, gays, and terrorists.  Use Firefox.  It's what the cool kids are using.

     

    Yeah! and Firefox is for hackers, gays, and n00bs. Use IEXPLORE. It's what i'm using.

  • Asd (unregistered) in reply to AndrewVos

    I have seen even worse than this. A recently hired "experienced" engineer not only did this for unit tests, he extended the junit assert class to put these method in. So instead of assertEquals("output string", result) we get FooAssert.assertResponse1(result)
    Joy.

  • richieb (unregistered) in reply to mrprogguy

    Actually, since the return value is a boolean why not simply say:

            return (condition)

    It really irks me when I see:

           if (some_bool)
              return true
           else
               return false


    ...richie
  • ChiefCrazyTalk (unregistered) in reply to Nand

    Nand:

    That case should be avoided as well. It's "bad" to drag along values (retval.) The function should return as soon as it's done working.

     

    OK, I only actually had one formal programming class in my life, and that was in 1983, but "Back in the day" we were always tought never to have multiple exit points for any function. 

Leave a comment on “Refactoring to the Max”

Log In or post as a guest

Replying to comment #:

« Return to Article