Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
function isLeapYear($year)
{
// if year isn't a multitude of 4, it isn't a leapyear
if (($year % 4) != 0)
{
return false;
}
// centuries that can't be divided by 400 aren't leapyears
if (($year % 100) == 0)
{
if (($year % 400) != 0)
{
return false;
}
}
// it must be a leapyear
return true;
}
No problem, but again I vote for multiple returns.
Hehe... You still did it in 7 lines of code...
I think there is always a way to do it with only one return. You see, if the code needs to use multiple returns (like the code timvw submitted), it is because the code can be re-designed in a better way (like the code harrisonad submitted.
OK the second function I gave could have a single return (would it be as readable though?). However, in the first - parse() - I really want to exit the loop immediately I find what I'm looking for rather than waste time churning through the full list. That means I need two returns
stukov wrote:
I think there is always a way to do it with only one return. You see, if the code needs to use multiple returns (like the code timvw submitted), it is because the code can be re-designed in a better way (like the code harrisonad submitted.
McGruff wrote:I don't think you can sustain that.
Really?
I disagree. In order to implement the version that harrisonad or myself showed we had to implement an extra local variable or suffer with extra nesting. If we needed a second flag variable, then it quickly gets very messy, each if starts to have lots of terms and more logical branches to worry about, or you end up with the deaply nesting problem. Additionally the large if is now less easily readablee, in my mind. Its harder to pick out the three leap year rules.
McGruff wrote:OK the second function I gave could have a single return (would it be as readable though?). However, in the first - parse() - I really want to exit the loop immediately I find what I'm looking for rather than waste time churning through the full list. That means I need two returns
instead of the foreach. In this case, you could have add another condition which would "break" the loop when the condition is met. Using a var which contains the value you will return, you could have only one return.
nielsene wrote:I disagree. In order to implement the version that harrisonad or myself showed we had to implement an extra local variable or suffer with extra nesting. If we needed a second flag variable, then it quickly gets very messy, each if starts to have lots of terms and more logical branches to worry about, or you end up with the deaply nesting problem. Additionally the large if is now less easily readablee, in my mind. Its harder to pick out the three leap year rules.
but I wouldn't really recommend that from a readable perspective.
Reduced doesn't mean clearer. Actually, I find harrisonad's version easier to read. But, what you are saying makes sense. Now again, which one should I trust? Dijkstra or nielsene?
OK, I wasn't sure if you were thinking shorter = better.
Obviosuly I'm less of an authority than Dijkstra. But most of his writings are also based aaround much earlier languange and pre-date a lot of OOP inspired theory, so I wouldn't use him as an absolute authority these days.
I'll still say that if you see a function that has deeply nested ifs and a single return you have a few options:
1. Switch some of the encasing if's to guard clauses that return early
2. See if Extract Method will help lower the nested-ness and increase readability
3. See if introducing extra, local flag variables lets you remove some nesting
and the expense of "simple" logic conditions.
I'm not saying you should always use one paticular method to fix the code smell, but don't throw away a method either.
[edit, fixed a confusing typo... easiler==>earlier]
Last edited by nielsene on Sat Jul 30, 2005 10:09 pm, edited 1 time in total.
I think "Structured Programming" was a logic consequence for the spaghetti code around those days, but i think it was more a case against goto than a case for one in and one out.
I'm aware that Dijkstra has proven that each (sub)program can be written with one in and one out. But i don't agree that it's always the most readable version.
high-level languages are meant to be readable to human. Yes, we can reduce our code to smallest as possible, but I am not sure if you can work with your team efficiently on practicing it.