
Notes on Programming in C (1989) - scapbi
http://www.lysator.liu.se/c/pikestyle.html
======
Peaker
> Simple rule: include files should never include include files. If instead
> they state (in comments or implicitly) what files they need to have included
> first, the problem of deciding which files to include is pushed to the user
> (programmer) but in a way that's easy to handle and that, by construction,
> avoids multiple inclusions. Multiple inclusions are a bane of systems
> programming. It's not rare to have files included five or more times to
> compile a single C source file. The Unix /usr/include/sys stuff is terrible
> this way.

> There's a little dance involving #ifdef's that can prevent a file being read
> twice, but it's usually done wrong in practice - the #ifdef's are in the
> file itself, not the file that includes it. The result is often thousands of
> needless lines of code passing through the lexical analyzer, which is (in
> good compilers) the most expensive phase.

> Just follow the simple rule.

This is a ridiculous stance, in my opinion.

Part of the appeal of libraries is _abstracting_ away implementation details.
I want to be able to have foo.h #include a hash table, or a binary search
tree, depending on #ifdef's or its internal implementation. The user of foo.h
shouldn't even have to know about it.

Compilers can easily memoize the position and parsed content of preprocessor
directives, and do a very quick skip of an #include file, as a much better way
to resolve the problem.

Rob's resolution is an instance of worse-is-better: Instead of slightly
complicating the lower-level tool (in this case, the preprocessor), let's
complicate all user code in existence.

~~~
pmarin
All Plan9 C programs are written in this way. Paradoxically the number of
includes in your code is minimal compared with the usual POSIX aproach. All C
programs begin with two includes: u.h and libc.h and usually libio.h and it is
often all you need for the startdard library.

The man pages of the libraries describe the libraries you need to include.

Example:

Plan9 cat: [http://plan9.bell-
labs.com/sources/plan9/sys/src/cmd/cat.c](http://plan9.bell-
labs.com/sources/plan9/sys/src/cmd/cat.c)

GNU cat:
[http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f...](http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/chcon.c;h=32d4b0f8b7aa98830ec6404c83801c5115f29854;hb=HEAD)

Plan9 du: [http://plan9.bell-
labs.com/sources/plan9/sys/src/cmd/du.c](http://plan9.bell-
labs.com/sources/plan9/sys/src/cmd/du.c)

GNU du:
[http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f...](http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/du.c;h=890edb64c31a41fdd0bf9a3f24607369c436928f;hb=HEAD)

~~~
ufo
Why do all the P9 files use `void main` instead of `int main`?

~~~
pmarin
Yes. Instead of returning an integer you use the function exits [1] and the
value appears in the shell variable status.

[1] [http://plan9.bell-labs.com/magic/man2html/2/exits](http://plan9.bell-
labs.com/magic/man2html/2/exits)

This is an introduction to programming in Plan9 C:

[http://doc.cat-v.org/plan_9/programming/c_programming_in_pla...](http://doc.cat-v.org/plan_9/programming/c_programming_in_plan_9)

------
eoi
It's interesting to see how some of these opinions are reflected in Go,
because Rob Pike helped design Go about 20 years after writing this essay:

Typography: Automatic formatting is part of the standard Go tooling and
culture.

Function pointers / Protocols: This section seems to be decsribing a technique
similar to Go's interfaces.

Include Files: Rob Pike talked about this in his presentation at SPLASH
[1,8:00-12:30]. He mentioned that Plan 9 had fast compile times in part due to
following this discipline. He contrasted that with one of Google's C++ code
bases in which the compiler had to read 2000 bytes for every byte of source.
That was largely because of includes, and was a problem for compile times. A
little later he talks about Go's method of importing dependencies, and
presents them as a big improvement to the situation.

[1][http://www.infoq.com/presentations/Go-
Google](http://www.infoq.com/presentations/Go-Google)

------
Zolomon
Nice list of books they have in their library:
[http://www.lysator.liu.se/lib/boklista.txt](http://www.lysator.liu.se/lib/boklista.txt)

------
ttty
" Procedure names should reflect what they do; function names should reflect
what they return." \- Never thought about naming this way, but is what I do (:

