[pacman-dev] Style questions and concerns

[Dave Reisner]

On Fri, Feb 25, 2011 at 10:27:13AM -0600, Dan McGee wrote:
> I've noticed these things a lot in recent patches, so let the
> discussion commence.
> 
> 1) typedef-ed structs. This is just a "copy the rest of them" habit,
> but I really feel we should stop doing this, only typedef-ing when we
> are making a public-facing type that we don't want to expose the
> internal contents of. Everything else should remain a struct type, and
> referred to as such, no typedef and no confusion that the fields are
> accessible.

Agreed. If it doesn't need to be opaque, then there's no reason to force
it.

> 2) return(value) style. This is a rule set in stone in the coding
> style doc but people are continuously breaking it. To be fair, it is
> silly, but mixing styles sucks way worse. I propose switching this,
> *BUT* all current patches need to follow current style, and if we
> switch, it should happen post-3.5.0 and in one commit, not this
> piecemeal junk.

Really just comes down to to stylistic preference. It's not a style I
prefer personally, but it's also not my personal project. I'm happy to
follow whatever we agree upon.

> 3) C99. Several patches are introducing things that go further down
> this road. I don't think they should all be avoided but I'm not sure
> GCC 3.X (Cygwin is still on this?) supports all of these.
>    * Variable declarations not at the start of a block. I'm not a huge
> fan of this, as I think having them at the start of the block helps
> clarify scope a lot better.
>    * Dynamically sized array declarations, e.g. data[numcpus]. I think
> this needs to be avoided, unfortunately, but it isn't hard to just use
> MALLOC/FREE in this case.
>    * C99 structure initialization (saw it in the parallelize patches).
> 

I see this as an all or none kind of deal. If we're going to make an
effort to avoid c99, I think we should avoid _all_ c99.

dave