Procnames Start Lines. But Why?
By Artyom BologovLooking at some old Open Source C codebase (everyone does that, right?) one can notice a weird convention. Procedure names and return types are split on two separate lines:
Pros of this style are
- It's easy to find procedure definition with
grep
: just search for/^procname/
. - It saves some space for argument list.
Especially when the return type includes qualifiers like
static
andconst
. Or something likestruct long_struct_name *
- K&R did that.
That's the reason someone on StackOverflow provided, but it's wrong.
"The C Programming Language" had return type on the same line as procedure name.
But! It also had
main()
starting the line, because it was possible to omit the "obvious"int
return type. That might be where the confusion started from.
Another reason, provided by Žarko Asen over email:
Relatively obvious cons are:
- It splits return type and name on separate lines. Looking up full prototype of the procedure is harder—one needs to open the file and look at the line above the name.
- It likely doesn't match the aesthetic preferences of most programmers and languages.
What I'm about to describe is a well-established synthesis of the two conventions: split and joined. This synthesis is:
- Let procnames start lines in source (.c) files.
- But list the whole procedure prototype on one line in header (.h) files.
This way, procedure prototype is easy to search for (look for .h files),
while the actual procedure source is equally easy to locate (/^procname/
).
Not forcing that on anyone, of course. But... does it make any sense now?