Ok I can understand that reasoning, except in this case, the original logic was a negative - so the given input wasn't validated right? So it isn't a pre-condition or is it? :)Well, I for one disagree ;-) I always return early for trivial cases, getting them out of the way, making it obvious that the meat or rest of a method works only for given validated inputs (pre-conditions of sort). It also avoids having to scroll down to figure out what happens next, like the value is returned as-is in this case.
In this case too, no extra code will be executed with only one return - there is still a check and if the condition fails (new code) it returns - so there's no impact on the performance - in effect you've retained your "trivial case" except that you've removed redundant code (an extraneous return).
I've personally only used an early return if there was no way I could think to create an elegant single return and in the case when performance was of paramount importance, and returning early would have saved a lot of extra effort for the VM.
Of course it depends on length of the method and over factors, butI'm always highly sensitive to local programming paradigms, and although I don't agree (I believe a single return reduces the complexity of code as there are fewer ways in which a method can terminate), I'm a relative newcomer to the code base and so I'll bow to superior experience and knowledge.
having a single return is not a criteria I rate highly when judging how
a method should be implemented. It's all very much in the eye of the
beholder. --DD
I'll just look for more little things I can adjust whilst I'm learning about the code base. Thanks for explaining your reasoning.
Kev
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
