Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: Map coordinate cleanups.
Home

[Freeciv-Dev] Re: Map coordinate cleanups.

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Marco Colombo <marco@xxxxxx>
Cc: Andreas Kemnade <akemnade@xxxxxxxxxxx>, Gaute B Strokkenes <gs234@xxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Map coordinate cleanups.
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 16 Aug 2001 16:45:53 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Thu, Aug 16, 2001 at 03:35:37PM +0200, Marco Colombo wrote:
> On Thu, 16 Aug 2001, Raimar Falke wrote:
> 
> > On Thu, Aug 16, 2001 at 01:47:28PM +0200, Marco Colombo wrote:
> > > On Thu, 16 Aug 2001, Raimar Falke wrote:
> > >
> > > > >  > Maybe it is time to decide which rule freeciv should follow. I 
> > > > > would
> > > > >  > vote for the extra {}s.
> > >
> > > Me too, for what it counts.
> > > <noflames>
> > > But I'm on the http://www.linuxhq.com/kernel/v2.4/doc/CodingStyle.html
> > > side, so I disagree with most of the "Mini Style Guide" section in
> > > freeciv_hackers_guide.txt.
> > > Well, only -i2 is real horror, to tell the truth.
> > > </noflames>
> >
> > Indeed doesn't the "Mini Style Guide" cover the brace issue.
> 
> Let's say it this way: if you put additional braces, you'll never *need*
> to remove them. On the converse, if you don't put them, one day you may
> find you need to add them (putting a second statement inside the same loop).
> 
> Exceptions:
> - one liner contructs:
>       if (!ok) goto error;
> 
> [RATIONALE: a {} block suggests that something it's being done ]
> 
> - empty loop blocks:

I usually avoid such constructs. I think they are ugly.

> 
>       for(<init code>; <cond code>; <incr code>)
>               ;
> 
>       or:
> 
>       for(<init code>; <cond code>; <incr code>)
>               continue;
> 
>       (the latter being my favorite)
> 
> [ the same ]

You don't have to argue with me. Freeciv just needs a rule.

> > > Anyway, I'm not sure one should have my_* functions everytime something
> > > useful isn't really portable... just my 0.02.
> >
> > Freeciv prefixes such cases with "my_" or "my" and I have also seen
> > such prefixes in other code.
> 
> I admit it's a matter of taste. From a readability standpoint, if I
> encounter a function called my_malloc(), I think that it's a non standard
> function, a memory allocator. It can be from a simple wrapper around
> system malloc(), to a more complex, completely different allocator.
> But it's a *different* function.

Yes, but if this function takes has a signature like "void
*my_malloc(int)" its semantics are clear. And in which way it
allocates the memory doesn't matter (at this level).

> If I see a my_ffs() function, I think it's somewhat different from the
> ffs() I'm familiar with, and I wonder how and why. Instead, if I see
> ffs(), I *know* what it does, and I don't wonder.

Ok so name the function "log2()" or something like this.

> So, the rule is: in C source, call the same functions with the same names,
> and use different names for different functions (and, slightly different
> names for slightly different functions, like my_* variants). How the
> `ffs' function name will lead to the actual implementation it's a
> linker job, and the C compiler (and the C source human reader) should
> not be concerned (well, not while compiling/reading the module that uses that
> function).
> I call that abstraction, too.

Also if names are prefixed with "my_" you get an extra layer where you
can put code. Like the check for no memory in the malloc() case.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx


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