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: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [PATCH] aiunit.c ai_manage_explorer cleanup (PR#1210)
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Thu, 10 Jan 2002 23:33:22 -0500

At 11:54 AM 02/01/10 +0000, Gregory Berkolaiko wrote:
> --- "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx> wrote: 
>> At 08:55 AM 02/01/08 -0800, Gregory Berkolaiko wrote:
>> >Few comments on the patch.

>There is truth in what you say.  But let's take an example:
>function find_something_to_kill, cycle starting at
>http://www.freeciv.org/lxr/source/ai/aiunit.c?v=cvs#L1254
>
>Two lines below there is an "if":
>
>1256     
>
>where does it end?
>
>scroll down... and down... and down...
>
>1427     } /* end if enemy */
>
>no else clause, but throughout 170 lines you keep expecting it.
>In this situation 
>
>if (aplayer == pplayer) {
>  /* we only attack our enemies */
>  continue;
>}
>
>would be so much better.

Agreed. I'm pretty flexible on a case by case basis and don't have
binary cutoffs on most style questions anyway.

>Of course the code blocks of such length just should not exist.
>And any patches that reduce the length by introducing calls to short
>functions should be welcome IMO.  In reality they get 10s of nitpick
>comments and get blissfully forgotten about.  
>
>As usual I start rambling about the sad fate of my patches, hehe ;)

It is therapy ... good in limited doses.

Contributory causes can be from many sources ... not only AI squinting. 

>> 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 :-).
>
>Fuzzy rules :)

I started off as a Fortran programmer. I can deal with the FP math :-).

But maybe it will help to state that a clear set of accepted practices
both as examples and concepts to apply written down in binary colours is 
fine.

The application needs to use a little common sense and accept a steady
move towards uniformity, rather than a barrier to movement short of
perfection.

Movement away from the style, i.e. chnaging things back can be a much
more binary decision.

Note this makes for good AI feedback rules as well :-).

>G.
>__________________________________________________
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>http://uk.my.yahoo.com

Cheers,
RossW
=====




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