Date: Sun, 22 Jul 2001 13:00:48 +0100 From: Paul Richards <paul@freebsd-services.co.uk> To: Bruce Evans <bde@zeta.org.au> Cc: Ruslan Ermilov <ru@FreeBSD.org>, Bruce Evans <bde@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/share/man/man9 style.9 Message-ID: <750530000.995803248@lobster.originative.co.uk> In-Reply-To: <Pine.BSF.4.21.0107221746120.24145-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Sunday, July 22, 2001 18:15:09 +1000 Bruce Evans <bde@zeta.org.au>
wrote:
> Everything is easier to read when it is outdented to column 0 and
> complicated surrounding context is removed :-). A real example would
> look more like:
>
> if (foo(verylongarg1, verylongarg2, verylongarg3) ==
> SLC_CANTCHANGE) {
> flag |= SLC_ACK;
> } else if (thisfunctionnameistoolongforitsowngood(arg1,
> arg2) == 1) {
> flag |= SLC_AGH;
> } else if (hislevel == SLC_CANTCHANGE &&
> mylevel == SLC_CANTCHANGE) {
> slctab[(int)func].current.flag = flag;
> }
>
That's a little contrived. The first if clause happens to indent to the
same level as the next line but that's rare in practice.
The first "else if" clause has bad style of it's own, no indenting scheme
is going to work if you use long function names, good programmers won't do
that so defining style based on other bad practices won't get us anywhere.
Even using
else if (thisfunctionnameistoolongforitsowngood(arg1,
arg2) == 1) {
flag |= SLC_AGH;
that's a horrible piece of code; the function name is too long and that's
the real style problem there.
The third second "else if" clause looks clean and it's much easier for the
eye to trace the conditions when they all start in the same place.
A more typical example would be
if (foobar(verylongarg1, verylongarg2, verylongarg3) ==
SLC_CANTCHANGE) {
flag |= SLC_ACK;
} else if (thisfunctionislong(arg1, rg2) == 1) {
flag |= SLC_AGH;
} else if (hislevel == SLC_CANTCHANGE &&
mylevel == SLC_CANTCHANGE) {
slctab[(int)func].current.flag = flag;
}
I'm starting to question whether style should drill down to such a low
level of detail. Most of the code in the tree that looks like it's in the
BSD style doesn't conform completely and in the end a good programmer knows
how to style a piece of code to be readable and that may be dependent upon
the particular vagaries of the code in question, as you've highlighted with
some corner cases above.
Perhaps style should mandate a basic BSD feel and then be less picky about
every little coding situation that may arise. My wife's a copy-editor and
she spends all day correcting "style" in manuscripts and in publishing
determining style is about setting a consistent feel, it's not a rigid set
of rules; the author has some leeway to write the manuscript they way they
prefer but they must write within the guidelines that the style requires so
that the work is consistent with other similar works.
I think we need to be more flexible along those lines. We need consistent
style, I'm a strong advocate of adhering to a project coding style, but
perhaps we're trying to apply engineering principles to something that is
artistic. As long as the style is consistent enough that it feels like BSD
code then it's probably acceptable for there to be some variations in
subtle ways based on the authors habits and preferences.
Therefore we should strive to determine what is required to attain a BSD
feel, rather than trying to nail down every single coding situation that
could possibly arise and mandating how code should be laid out in such
circumstances.
Paul.
Paul.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?750530000.995803248>