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>