From owner-freebsd-current@FreeBSD.ORG Thu Mar 2 16:35:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23C8A16A423 for ; Thu, 2 Mar 2006 16:35:31 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F30A43D45 for ; Thu, 2 Mar 2006 16:35:30 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1ADD146B04; Thu, 2 Mar 2006 11:35:10 -0500 (EST) Date: Thu, 2 Mar 2006 16:40:01 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Dmitry Pryanishnikov In-Reply-To: <20060302105229.P83093@atlantis.atlantis.dp.ua> Message-ID: <20060302163633.H77029@fledge.watson.org> References: <20060302105229.P83093@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: style(9) question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 16:35:31 -0000 On Thu, 2 Mar 2006, Dmitry Pryanishnikov wrote: > I apologize for asking here my question (it should belong to -questions, > but the most developers are available here, and I just hope it won't hurt). > What's the historical reason of the following style(9) advise: > > Values in return statements should be enclosed in parentheses. > > What's the rationale of this? From time to time I see small commits just > changing "return foo;" -> "return (foo);". I think the first form is quite > natural and not ambiguous. Shouldn't we remove this advise from style(9)? Usually, these changes are a precursor to a larger semantic rewrite of code, where the new code being written conforms more to style(9) than the old code. This breaks out the style changes from the semantic changes. You generally won't see style changes for the sake of style changes (although there are some exceptions: for example, license formatting to make it mechanically parseable, or changing the C prototype style so that more type checking can be performed). Regarding the contents of style(9) -- generally, we try hard not to change the style guide, as style proves to be a rather contentious topic, as it is typically guided much more by opinion and taste than function. Often, ambiguities in the style guide are resolved by looking at what "most" cases in the kernel tree currently do, then documenting that as the right way to do it. I can't really think of a good reason for return (foo) over return foo, but changing it will just make a bunch of code that previously conformed to the style guide cease to do so, which probably doesn't really improve matters :-). Robert N M Watson