[Toybox] include guard

[Rob Landley]

On 03/06/2012 05:15 PM, Alex wrote:
> I just took a brief look a the source code for some of the components in
> this project, which BTW I think is a great and the code looks really
> neat, and saw the use/need of includes to toys.h in many files.

Yup, once for each file.

> I was wondering why you don't have an include guard like...
> 
> #ifndef _TOYS_H
> 
> #include "toys.h"
> 
> #define _TOYS_H
> 
> #endif

We're not providing this file for other people outside the project to
use, so we're not worried about random third parties potentialy misusing
our code.  We're worried about _us_ misusing our code, and we can deal
with that by not doing it.

Keep the code simple, and everything else works out:

  http://www.jwz.org/doc/worse-is-better.html

Note that standard system headers in /usr/include include each _other_,
thus often get redundantly included even if each .c file only includes
each one once.  We include toys.h exactly once from each .c file, and
it's often the _only_ header we include.

(Besides, if we were going to use an include guard, we'd put it in the
.h file itself instead of at each call site.  But it's our code and
should only be included once, so I didn't bother.)

> ...instead of the one-liner includes to make sure, in this case, toys.h
> is not been added several times over?

Because we're the ones #including it and know not to do that, and if we
did it would be an obvious build break anyway?

> Sorry if this is been taken care
> some place else and I didn't see it.

This is called defensive proramming, and we don't do it:


http://danielroop.com/blog/2009/10/15/why-defensive-programming-is-rubbish/

Defensive programming adds checks to deal with "what if this code is
used wrong", but we're the ones using it.  If we screw up, we fix it.
If we need a bigger test suite, or more code review, we do that.  We
don't make the code bigger and more complicated with checks which we
believe should never actually be needed.  If code isn't needed, it
shouldn't be there.

This is related to keeping the code small: if we don't know what we're
sucking in, we can't keep the size or complexity down.  If we _do_ know,
we can just do the right thing in the first place.

Rob