style.9 RFC: Permit eliding blank lines in small functions

Bruce Evans brde at optusnet.com.au
Tue May 28 22:13:56 UTC 2019


On Tue, 28 May 2019, Conrad Meyer wrote:

> I have proposed a small change to style.9 here:
>
> https://reviews.freebsd.org/D20448

Why not propose it here (on this list).

> I believe this has been generally permitted in practice and the change
> is mostly to codify existing unwritten standards, rather than to
> change them.  The goal of this thread is to determine if we do have
> general consensus for the concept.

It is a strange not very good rule, but it is a fundamental part of KNF.

The wording for the change is bad.  "excluded" makes no sense.  It
means closer to "omitted".  "may be excluded" means "the empty line
required by the previous clause is not actually required [for short
functions]".

Another bug in this section is the use of "empty" for lines.  Everywhere
else in style(9) (4 instances) uses the less precise term "blank".
indent(1) consistently uses "blank" (11 instances), including for its -sob
option for removing evil b's.  The SunOS/zol style guide also has bugs in
this area.

-sob is specifically documented in indent(1) as being good for removing
this particular optional blank line, but the man page is out of date.
indent also has options -[n]bad and -[n]badp which interact in confusing
ways with -sob even if you know that they exist and what they are set to.
indent of course doesn't understand "may be excluded" so with a KNF
.indent.pro it fixes any exclusions.  -[n]badp was added to it recently
to give more control over the blank line after the first set of declarations
when this set is null.  This area would be even more complicated and buggier
if indent understood "may be excluded".  It would need something like a
numeric arg for -[n]badp to allow exceptions for short functions.

Bruce


More information about the freebsd-arch mailing list