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.
> 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
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
-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.