[Freeciv-Dev] Re: (PR#7075) break and continue in iterators

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7075 >


We are in violent argreement in all but emphasis on religious vs
technical background reasons.

IMHO, it is better though to actually understand the hard technical
rationale, rather than just repeat subjective mantras used to reinforce
behaviour in the absence of understanding. Unfortunately, in this era
where the religion/belief vs science/understanding wars are being
refought by the new religion of political correctness, the latter seems
easier and is often the more prevalent choice :-).

Jason Short wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7075 >
> 
> Arnstein Lindgard wrote:
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=7075 >
[...]
>>If "goto" is perfectly valid C, less ambigous and equally well
>>defined as "break", then what exactly are the reasons for
>>discouraging it's use?
> 
> Goto is less elegant and breaks some other code (like list iterators). 

Break or goto should have equivalent functionality except in cases where
loop or code block boundaries limit the scope of break. Break is usually
the problem case to code in deeply nested scenarios because of its
limitations. It is the power of unconstrained GOTOs that generally lead
to abuse and the bad name.

Of course, the final assembly code is indistinguishable from use of explicit
GOTOs in either case :-).

> But the worst is to force the use of break in some places and the use of 
> goto in others.

This is not a problem as long as conditions are clearly spelled out, aka
documented in code comments. Worse only really applies when the conditions
are not common knowledge and obscured, and I agree this is very bad. Good
programmers will always handle pitfalls or alternate coding models correctly
as long as they are recognized and not hidden booby traps. Thus documentation
can be a valid alternative to code rewrites and purges.

> I agree with Ross: the iterator should be rewritten to use a single loop.
> 
> jason

Knowing why one construct or the other is valid in a given scenario is
usually a much better way to arrive at robust code than just heaping scorn
on one practice or the other.

Cheers,
RossW
=====