Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2002:
[Freeciv-Dev] Re: [PATCH] aiunit.c ai_manage_explorer cleanup (PR#1210)
Home

[Freeciv-Dev] Re: [PATCH] aiunit.c ai_manage_explorer cleanup (PR#1210)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx, bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [PATCH] aiunit.c ai_manage_explorer cleanup (PR#1210)
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Wed, 09 Jan 2002 20:06:49 -0500

At 08:55 AM 02/01/08 -0800, Gregory Berkolaiko wrote:
>Few comments on the patch.
>
>3. Splitting of long if (...) condition into many if() continue;
>is nice.  There is another place that you can do the same.
>
><ASIDE>
>I really prefer statements like
>       if (!points_left) continue;
>to 
>       if (points_left) {
>         /* very long block */
>       }
>as it explicitly says that there will be no "else" 234 lines down the
>code, it also reduces indentation which is sometimes hard to trace.
>Shall we include it in the style guide?
></ASIDE>

I'm not unhappy with this particular example, but generally dislike
this sort of construct in most settings. I am sure there are those 
who will find all sorts of means to pervert this in ways to destroy
useful coding patterns.

Complex conditionals are to be avoided where reasonable, but it is
usually better to work out the logic of multiple conditions than 
duplicate the code or access it with a maze of explicit gotos.

This is almost a goto construct which is why it is tricky to manage
and easy to abuse.

If you make the continue; a return; it tends to make functions very
inscrutable. They should only have one return point. 

It is almost always useful to have the code guarded by a condition 
within and bracketted by the if-clause, rather than disconnected from it.

But, I tend to order things to keep the else in visible range of the 
if as far as possible in dual block cases, and avoid indenting if
reasonable.

It would be good to maybe have suggested, style guides with a weight
that gives some latitude for greyness in application, or else the
guideline should be limited to super-majority concensus cases of abuse 
only :-).

>Best,
>G.
>
> --- Petr Baudis <pasky@xxxxxxxxxxx> wrote: 

Cheers,
RossW
=====




[Prev in Thread] Current Thread [Next in Thread]