Date: Fri, 29 Jan 1999 19:21:23 +1100 From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> To: dillon@apollo.backplane.com, grog@lemis.com Cc: current@FreeBSD.ORG Subject: Re: indent(1) and style(9) (was: btokup() macro in sys/malloc.h) Message-ID: <99Jan29.191155est.40324@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
Matthew Dillon <dillon@apollo.backplane.com> wrote: >:Judicious use of inline functions (and macros) should help move >:code to the left - and may even make it more understandable. > > More then judicious use -- inlines are an incredible advantage. Most > people don't realize that GCC will optimize constant arguments through > an inline call. GCC inserts the called function's parse tree into the calling function and then optimises the overall parse tree. inline functions are not a total panacea. They don't work in the following situations: 1) If the inlined function is just a thrown-together collection of miscellaneous statements, the final result will be less readible than the original. 2) The block of code needs to alter the value of more than one variable. 3) The block of code refers to a large number of local (to the calling function) variables. 4) The block of code includes return's or goto's. Greg Lehey <grog@lemis.com> wrote: >One man's readability is another man's illegibility. Agreed. We are discussing highly subjective issues. > I certainly think that macros can really obfuscate things. I'm less keen on macros. Their sole advantage (also a major disadvantage) over inline functions is that they share the same namespace as the calling function. > And moving code away >into separate functions also makes it difficult to see the Big >Picture. If the functional decomposition is done appropriately, and the inlined functions are given meaningful names, then it should become _easier_ to see the Big Picture - because the calling function is not so cluttered. > On the other hand, I very much *do* support a consistent coding style. The FreeBSD probject _does_ need a documented coding style - which is followed. style(9) meets this requirement. I don't believe that style(9) should be treated as infallible doctrine, written in stone. Coding practices need to evolve to meet changing requirements and expectactions - otherwise we'd all still be programming in machine language, following the guidelines laid out in Wilkes, Wheeler, Gill[1]. As a further discussion point, can I suggest reference to one or more of the following: I found most of these in ftp://archive.cis.ohio-state.edu/pub/style-guide, but that was several years ago. L. W. Cannon et al, "Recommended C Style and Coding Standards", 1989 A. Dolenc et al, "Notes on Writing Portable Programs in C", 1990 Expert Systems Australia, "C Style Guide", 1991 R. Pike, "Notes on Programming in C", H. Spencer, "The Ten Commandments for C Programmers", Annotated Edition. H. Spencer, "How to Steal Code or Inventing the Wheel Only Once", R. Stallman, "GNU Coding Standards", D. Straker, "C Style: Standards and Guidelines", Prentice Hall, 1992. [1]: M Wilkes, D Wheeler, S Gill, "The Preparation of Programs for an Electronic Digital Computer", Addison-Wesley, 1951. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Jan29.191155est.40324>