Messages in this thread | | | Date | Wed, 6 Apr 2005 13:28:38 +0200 | From | Jörn Engel <> | Subject | Re: RFC: turn kmalloc+memset(,0,) into kcalloc |
| |
On Tue, 5 April 2005 22:01:49 +0200, Jesper Juhl wrote: > On Tue, 5 Apr 2005, Roland Dreier wrote: > > > > or simply > > > if (!(ptr = kcalloc(n, size, ...))) > > > goto out; > > > and save an additional line of screen realestate while you are at it... > > > > No, please don't do that. The general kernel style is to avoid > > assignments within conditionals. > > > It may be the prefered style to avoid assignments in conditionals, but in > that case we have a lot of cleanup to do. What I wrote above is quite > common in the current tree - a simple egrep -r "if\ *\(\!\(.+=" * in > 2.6.12-rc2-mm1 will find you somewhere between 1000 and 2000 cases > scattered all over the tree. > > Personally I don't see why thy should not be used. They are short, not any > harder to read (IMHO), save screen space & are quite common in userspace > code as well (so people should be used to seeing them). > > If such statements are generally frawned upon then I'd suggest an addition > be made to Documentation/CodingStyle mentioning that fact, and I wonder if > patches to clean up current users would be welcome?
I _do_ change them whenever they occur in code I maintain. And each time, it is an improvement.
o Functional code always has the same indentation. I can mentally ignore the error path by ignoring all indented code. Getting a quick overview is quite nice.
o Rather often, your preferred variant violates the 80 columns rule. If I need the line break anyway,...
o Keeping condition and functional code seperate avoids the Lisp-style bracket maze. Some editors can help you here, but not needing any help would be even better, no?
Jörn
-- Mundie uses a textbook tactic of manipulation: start with some reasonable talk, and lead the audience to an unreasonable conclusion. -- Bruce Perens - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |