Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Mar 2009 11:16:02 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Christoph Mallon <christoph.mallon@gmx.de>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, Andriy Gapon <avg@freebsd.org>, marius@alchemy.franken.de, svn-src-head@freebsd.org, "M. Warner Losh" <imp@bsdimp.com>
Subject:   Re: svn commit: r190098 - in head/sys/sparc64: fhc sparc64
Message-ID:  <49C68062.2000407@elischer.org>
In-Reply-To: <49C5FCCA.5010509@gmx.de>
References:  <49C4C974.5050209@gmx.de>	<20090321130332.GD67783@alchemy.franken.de>	<49C5737F.1050902@gmx.de>	<20090321.175756.-434257642.imp@bsdimp.com> <49C5F88C.3070600@freebsd.org> <49C5FCCA.5010509@gmx.de>

next in thread | previous in thread | raw e-mail | index | archive | help
Christoph Mallon wrote:
> Andriy Gapon schrieb:
 >> compliants about style (9)
 > agreement and disagreement.


basically almost every single committer who comes into the group
usually starts up by objecting to one part or another of the style
guide. However the problem is that we all object to different parts
and those parts that others disagree with are often parts that
we see as being reasonable.


examples:
" I wan to go > 80 columns".

and

"I often end up debugging on the console. thank goodness the
sources fit in 80 columns".


The style guide IS open to change but not by any individual
contributer.  Most of the things in there are there for a reason that
is non obvious.   Sometimes they are arbitrary.


If one has read BSD code and other system code however, one is 
sometimes struck with how uniform the BSD code is. Once you get
the style into your head you can start taking shortcuts.. For
example you know where all the locals are, and you can see from
an quick look how much stack space a particular function is
contributing to using up the very limited stack space available
in kernel.

At this stage you will find that there are just some things
you will have to live with because changing them now would make new 
sources just too different too old sources.
(I'd put indent rules and 8-char tabs into that category.)
There are other things that will be amenable to change with sufficient
discussion.  Due to different compiler rules for example, there may be
reason to drop some rules because they were there to stop people
from making mistakes that teh compiler now warns about. But generally
every change needs to pass one question.

"Will the code still largely 'smell' like BSD code?"





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49C68062.2000407>