Richard said:
Ben Bacarisse <
[email protected]> writes:
<big snip>
I don't think there are any substantive issues there than this:
I do not. But I am a bit bewildered by your arguments here. Nothing you
have said is easier or "more maintainable" (in my mind of course) than
my example which is concise, easy to read and very, very localised
without the need to check for else statements.
Once more
while(n--){
if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */
/*do processing of things we are interested in*/
}
Has to be easier to comprehend and check than:
while(n--){
if(complexConditionMatched(n)){
/*do processing of things we are interested in*/
}
}
because in the second block one MUST go down to check the end of the
function to see what happens for the non matched element.
Why are you bringing up "easier to understand" -- I agreed about that
several messages ago?
The only issue I raised was maintainability. Now, I have admitted
that I don't really know what people mean here, but you brought it up
so it must mean something to you. I asked for an example of something
that, in your view impairs maintainability, but you did not offer one.
Without that I will be at a disadvantage, because I don't know what I
mean by it and you haven't said what you mean by it!
Other people seem to hold that code is more maintainable if it can be
modified by making "local changes". I posited a change: add something
that has to be done every time after the loop's (current) body. To do
that, if a loop has a continue, the maintenance programmer has to
check for that and either replace the continue with a goto or re-write
using an if that encloses the (current) body. Neither is what I
understand by a "local change".
This may not be what you mean by maintainability, in which case you
use is (by your criteria) unimpeachable, but it seems to match what I
think other people call maintainability.
Please don't repeat that your code if for cases where this change is
never warranted. If you can code for all future changes you should
write a book to tell the rest of how to do this. If, on the other
hand, you claim that this change is never need in loops that have this
specific pattern, then I'll shut up and just accept you have a much
deeper knowledge of code patterns than I have ever managed to attain
(but you should have brought up the fact that you know this never
happens when you offered the code pattern).