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
