Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.object Subject: Re: Functions without side effects (was Old confusion) Message-ID: <1991Jun23.025529.7749@netcom.COM> Date: 23 Jun 91 02:55:29 GMT References: <130242@tut.cis.ohio-state.edu> <4888@osc.COM> <72893@microsoft.UUCP> <4116@ssc-bee.ssc-vax.UUCP> <4907@osc.COM> <1991Jun19.173 <1991Jun21.013944.23970@netcom.COM> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 65 >Often one hears claims that whitespace is `cheap' or `free'. This is NOT true. >Strunk & White's Little Book stresses brevity's importance to clarity, a lesson >we should not forget. Strunk & White's little book explains how to write readable ENGLISH. It does indeed stress brevity's importance to clarity, but not to the point that it says to leave out all the vowels, to concatenate two adjacent words instead of preserving separation (e.g. the underscore), to eliminate punctuation, etc. Brevity should not be so slavishly emphasized as to affect comprehensibility, another lesson we should not forget. > # Comment Spacing Device Font > print("I love named parameter names", 5, laserprinter, helvetica); > print("My kingdom for a comment", 5, laserprinter, helvetica); > print("Self-documenting code? Hah!", 5, laserprinter, helvetica); > print("Pork bellies are looking good", 5, laserprinter, helvetica); >The latter is 25% shorter in vertical space, 25% longer horizontally, 50% the >number of characters, and a hundredfold more readable because the statements >are short enough to be written in a tabular fashion. The only expense, as far >as I can tell, is that the latter version is less tolerant to changes in the ^^^^^^^^^^^^^^^^^^^^^^^^ >function. A mere triviality, I'm sure--just ask any maintenance programmer... ;-) As a general, probably fundamental rule, the more information you can place IN THE CODE, and the more often you can do this IN ONE AND ONLY ONE PLACE, the more maintainable your code. I regard most comments as an admission of failure and/or a design flaw in the implementation language. Incidentally, as long as we're talking about multi-call cases, Ada has features to support this too--and without comments, with a single point of maintenance, and with even fewer arguments than in your example above (why is it I am always arguing Ada with people who don't know it, even though I DO know C and C++?). In Ada, I'd write the above as: procedure Default_Print (This_Comment : in String; With_Spacing : in Positive := 5; On_Device : in Printers.Kind := Printers.Laserprinter; In_Font : in Fonts.Kind := Fonts.Helvetica) renames Print; Default_Print ("I love named parameter names."); Default_Print ("My kingdom for a comment."); Default_Print ("Self-documenting code? Hah!"); Default_Print ("Pork bellies are looking good."); Default_Print ("Your move."); The "renames", by the way, is strictly a syntactic artifact--it has no run-time overhead, nor does it occupy space in the end executable (it is eliminated by the compiler). >There's a better example I'd love to harp on, the common practice of devoting >an entire line to compound statement delimiters. An ENTIRE LINE!?!?! For shame--just think of all that wasted disk space. ;-) -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *