one return per method

meh.as

// a difference is not a difference unless it *makes* a difference

public function add(item:*):Boolean
{
    if (contains(item))
        return false;
    
    push(item);
    return true;
}

public function add(item:*):Boolean
{
    var notContained:Boolean = !contains(item);
    if (notContained)
        push(item);
    
    return notContained;
}

Interesting point David. I agree that there is a point at which adding guard statements stops making sense, and that your definition is much better than the one with all the guards. I don't see why acceding that there is a point at which one becomes more readable than the other means you must deny the readability of guards under any circumstances.

I'm starting to frame this debate in my mind with you and squeedee at opposite ends of a spectrum. I'm not taking sides in this except to acknowledge that I lean a little more towards squeedee's approach than to yours, but I am curious about why both of you strongly feel the need to take an aggressive position about this.

well we have two issues now.. On the original one, I never claimed that Guards are outright the right way. Just that they are awesome.
I originally got concerned that Tanya thought they're "Bad" and then was as amazed as you were at the outright position that Dave took.

If i can read it and make sense of it quickly, then i love it. Ergo, i have no issue with Dave's version... except... issue 2:

What I take to be a misunderstanding of Bob Martin's attempt to explain "when has extract method stopped being useful" and "how to name a function"

Describing the behaviour of the method does not necessarily make it an 'and'. I think i've outlined why I think this above?

I'm with squeedee. Guard clauses rule; conditional slaloms drool.