chris@mimsy.UUCP (Chris Torek) (04/02/88)
Spotted in a signature in sci.med: It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage, than the creation of a new system. For the initiator has the enmity of all who would profit by the preservation of the old institutions and merely lukewarm defenders in those who would gain by the new ones. -Machiavelli -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jseymour@medar.com (James Seymour) (04/03/91)
Well, I've mangaged to get my backside in hot water in other newsgroups lately, why not here as well :-). We're getting ready to update our in-house Software Quality Assurance Plan (which includes some "style" guidlines to make things easier for multi-programmer projects), and there are some issues we want to address and I'm looking for some direction. There are two points: 1) We've been using the K&R format for function definitions, while the new ANSI format is like the Pascal format (for example). The K&R Second Edition states that the original K&R form will be supported at least during the "transition period". Does the ANSI standard eliminate the original K&R format (eventually)? Even if it doesn't, does it look like that's the way "everybody" will be doing it in the future? Btw: I've yet to see code from any source using the new ANSI format, other than examples in some texts. 2) Parenthesis are not required for return statements, but according to the Second Edition K&R work, they are, and will remain, acceptable. I *have* seen lots of code where the parens are not used. Does this seem to be the way most folks are heading? If so, why? (Personally, I prefer the original K&R forms for both of these, as do most of the engineers here). Thanks in advance for any feedback. -- Jim Seymour | Medar, Inc. ...!uunet!medar!jseymour | 38700 Grand River Ave. jseymour@medar.com | Farmington Hills, MI. 48331 CIS: 72730,1166 GEnie: jseymour | FAX: (313)477-8897
steve@taumet.com (Stephen Clamage) (04/05/91)
jseymour@medar.com (James Seymour) writes: >1) We've been using the K&R format for function definitions... The K&R > Second Edition states that the original K&R form will be supported > at least during the "transition period". Does the ANSI standard > eliminate the original K&R format (eventually)? Yes. Non-prototype declarations are called "obsolescent" meaning that they may be illegal at some future time. >2) Parenthesis are not required for return statements, but according to > the Second Edition K&R work, they are, and will remain, acceptable. The return keyword is optionally followed by an expression, and finally by a semicolon. No expression can contain a semicolon. Adding parentheses around an expression makes it neither more nor less an expression. The parens are not part of the return statement syntax. They are redundant, not required, and not forbidden. I don't know why this keeps coming up. -- Steve Clamage, TauMetric Corp, steve@taumet.com
gwyn@smoke.brl.mil (Doug Gwyn) (04/05/91)
In article <104@hdwr1.medar.com> jseymour@medar.com (James Seymour) writes: >Does the ANSI standard eliminate the original K&R format (eventually)? No. It is flagged as an "obsolescent feature", which serves two purposes: it encourages programmers to not use it unnecessarily, and it indicates to future C standardization committees that X3J11 considered it appropriate for this feature to be considered for removal in some future C standard. However, its removal at some future date is not mandated. >...does it look like that's the way "everybody" will be doing it in the >future? Btw: I've yet to see code from any source using the new >ANSI format, other than examples in some texts. I think most serious development of portable applications in C at present has to accommodate compilers that support only the old style of function declaration. What some of us have done is to, in one way or another, key on the __STDC__ macro to determine whether or not the prototype form is employed, but maintain the policy of not relying on the special behavior of prototypes (i.e. no automatic conversion of arguments, and use solely of default-widened parameter types). >2) Parenthesis are not required for return statements, but according to > the Second Edition K&R work, they are, and will remain, acceptable. > I *have* seen lots of code where the parens are not used. Does this > seem to be the way most folks are heading? If so, why? Parentheses are always allowed around expressions. There is no reason to expect that to ever change. Use of redundant parentheses is purely a stylistic issue.
jseymour@medar.com (James Seymour) (04/06/91)
In article <651@taumet.com> steve@taumet.com (Stephen Clamage) writes: |jseymour@medar.com (James Seymour) writes: | ||2) Parenthesis are not required for return statements, but ... | |They are redundant, not required, and not forbidden. I don't know why |this keeps coming up. | In my case: because (once again) my fingers ran faster than my brain :-). If I'd thought it through, I'd have realized that an expression is an expression. |-- |Steve Clamage, TauMetric Corp, steve@taumet.com -- Jim Seymour | Medar, Inc. ...!uunet!medar!jseymour | 38700 Grand River Ave. jseymour@medar.com | Farmington Hills, MI. 48331 CIS: 72730,1166 GEnie: jseymour | FAX: (313)477-8897
sarima@tdatirv.UUCP (Stanley Friesen) (04/13/91)
In article <104@hdwr1.medar.com> jseymour@medar.com (James Seymour) writes: >1) We've been using the K&R format for function definitions, while the > new ANSI format is like the Pascal format (for example). The K&R > Second Edition states that the original K&R form will be supported > at least during the "transition period". Does the ANSI standard > eliminate the original K&R format (eventually)? Even if it doesn't, > does it look like that's the way "everybody" will be doing it in the > future? Btw: I've yet to see code from any source using the new > ANSI format, other than examples in some texts. The old style of function declarations is not eliminated in the ANSI standard but it *is* depreciated. That is it is listed as an obsolete feature subject to deletion in some unspecified future version of the standard. [The anticipated date for the next version is often cited as 2001]. Thus everyone *will* be shifting to using the new style function declarations, but *very* slowly, since many existing compilers do no support them, and many non-ANSI compilers will continue to be used for many years to come. Many developers are using a hack involving #ifdef to provide both styles in the same source code. >2) Parenthesis are not required for return statements, but according to > the Second Edition K&R work, they are, and will remain, acceptable. > I *have* seen lots of code where the parens are not used. Does this > seem to be the way most folks are heading? If so, why? The parentheses have not been required for a very long time. (Not even when K&R I was published). The value of a return statement is any expression, and since an expression in parentheses is always equivalent to the same expression without parentheses, they are and will remain optional in this context. >(Personally, I prefer the original K&R forms for both of these, as do > most of the engineers here). The use of parentheses around return values is a style matter, and is of little real importance to code quality. It should be left to the individual programmer. The new style function declarations are a vast improvement over the old, since they allow more exact type checking by the compiler. Thus they are to be prefered if your compiler is ANSI. The most effective way to use the new style declarations is to place a prototype for every externally visible function into some header file that is included everywhere the function is used and also where it is defined. This provides maximum type safety. -- --------------- uunet!tdatirv!sarima (Stanley Friesen)