Date: Thu, 06 Feb 1997 18:00:52 +0100 From: Eivind Eklund <eivind@dimaga.com> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: chat@freebsd.org Subject: Re: cvs commit: CVSROOT avail Message-ID: <3.0.32.19970206180051.00abec10@dimaga.com>
next in thread | raw e-mail | index | archive | help
At 12:30 PM 2/3/97 -0500, Garrett Wollman wrote: ><<On Mon, 03 Feb 1997 15:50:56 +0100, Eivind Eklund <eivind@dimaga.com> said: > >> Is it only for hystorical reasons that most things still are K&R? > >Well, it depends on which part of `K&R' you are referring to. It is >indeed only for historical reasons that many user programs have no >parameter type-safety at all. However, most newer code will have >prototypes even if the function definitions are still in the >traditional format (which some people prefer, although I'm not one, >and which the style guide still strongly encourages). "Strongly encourages" == "We could not agree. For new subsystems, choose what you feel is more important"? :) Anyway; I would not recommend using ANSI prototypes and K&R style definitions - this can create some weird parameter conversions which are unlikely to give much problems on a machine with pure 32-bit parameter passing, but can potentially give weird problems on later ports. Besides, C9X at least seemed to be going to abolish K&R style function prototypes (which was what I meant). I'll get back to you on whether they still plan to do that. >My approach would be to follow traditional style in terms of >indentation, brace placement, comment formatting, spacing, and so on, >but to always use new-style function declarations and definitions in >new code. Agreement from me. Are there (still, 2 years after the copyright on style(9) ) enough people out there that disagree strongly enough that it would be wrong to recommend this? >Some other rules which are not all entirely written down, >and some of which disagree with style(9): > >5) Never use NULL. Write it `0', and provide casts as appropriate. This is makes it more difficult to see, and provide less typechecking. Casts must be provided as appropriate, of course. >7) Don't use continuation lines in strings. Are you really talking of continuation lines, or do you mean string concatenation or in-string newlines? (Not using continuation lines seems so obvious when string concatenation is available - if it is tolerated.) >11) Don't use in lint(1) ``control comments''. Nobody uses lint. I've just turned into "nobody". :) >> If there isn't any guidelines, I believe some guidelines for which style we >> want (not require) for submissions to FreeBSD might be a good thing - I can >> throw together a draft and throw it at -hackers. > >Actually, throwing it at -hackers is probably counterproductive. >Throw it at cvs-committers; these are the people for whom it really >makes a difference. I'll see if I can find the time to do this one day not too far into the future - I can probably adopt part of the "good coding practice" parts from a document I've written for my company. Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ <eivind@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.32.19970206180051.00abec10>