[FFmpeg-devel] [VOTE] Multiple inclusion guards in headers
Mon Aug 18 09:33:42 CEST 2008
On Mon, Aug 18, 2008 at 08:59:50AM +0200, Diego Biurrun wrote:
> On Mon, Aug 18, 2008 at 08:49:31AM +0200, Reimar Doeffinger wrote:
> > On Sun, Aug 17, 2008 at 07:17:22PM +0200, Michael Niedermayer wrote:
> > > This is the second issue id like to see clarified
> > >
> > > Do we require headers that do not need multiple inclusion guards out of
> > > technical reasons to have multiple inclusion guards?
> > > technical here is speed, compiler warnings or errors, or spec compliance
> > >
> > >
> > > My vote is of course, no, as it makes the headers bigger and thus means
> > > more to read aka worse readability.
> > I do not think the overhead of these is significant and avoids the annoyance
> > of possibly having to add them later.
> > I am against making a big deal about it though, this is nothing critical and
> > while everyone should make an effort to remember adding them, forgetting
> > it should not lead to flaming - IMO it might be a good idea to here "discard"
> > the normal commit rules and allow everyone to add them without sending a patch first...
> So you want to start handing out licenses for sloppyness? That's one
> hell of a slippery slope...
We are talking about 3 lines of trivial code. Yes, I think there is no problem with
risking being a _bit_ more sloppy than usual.
Note that I don't want to see this applied to the license headers, they are much too
easy to mess up in a slight but relevant way (though I agree there should be a more
automated way to handle them - if not as commit hooks maybe as part of make test,
or how about a script that adds those headers? IMO less risky than relying on copy-
More information about the ffmpeg-devel