Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!dimacs.rutgers.edu!aramis.rutgers.edu!paul.rutgers.edu!brushfire.rutgers.edu!gaynor From: gaynor@brushfire.rutgers.edu (Silver) Newsgroups: comp.object Subject: Re: Functions without side effects (was Old confusion) Message-ID: Date: 23 Jun 91 23:12:51 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: Rutgers Univ., New Brunswick, N.J. Lines: 116 Good, good. The last time I made a similar posting, no one would bite. > Brevity should not be so slavishly emphasized as to affect comprehensibility, > another lesson we should not forget. I just read your Unix flame, and agree with many of your points, the same way I agree with the above line. I AM NOT saying toss clarity for brevity. I AM saying that the value of brevity should be accomodated when considering clarity. > 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. You cite a major consideration, but not the only one. How local is the definition of Default_Print to its use in the code? Does keeping it local break other conventions? Is it worth the trouble of adding it? By doing so, you double the code length in this example. (That is, it's more than a small constant amount of extra code. Otherwise the answer is of obviously "Yes.".) > I regard most comments as an admission of failure and/or a design flaw in the > implementation language. This is too easy a mark at face value. Please qualify. In general, I'll say that like anything else, comments can be abused. ;; Increment page counter is usually a total abuse, unless it is documenting something less intuitive than (setq page (+ page 1)) or there is some virtue to its placement. For instance, documenting the trivial `then' clause of a conditional to provide a visual match for the `else' clause. To wit, /* No further processing is usually required. However, such-n-such */ /* sometimes forces the condition, which is relatively rare. */ if (condition) then {/* Increment page counter */ i <- i + 1} else {/* An exception has occurred, probably by such-n-such. ... */ ...} > (why is it I am always arguing Ada with people who don't know it, even though > I DO know C and C++?) First off, I know or am familiar with all the languages in question, albeit some to a better extent than others. Second, Ada is not the be-all-end-all of languages. It has its good points and its bad points. Without spending a lot of time critiquing Ada, I'll simply say that I can appreciate some of its features without being terribly fond of it in general. In looking at your Default_Print, it's just too verbose for the job, and non-local. Consider #define _local_print(comment) print(comment, 5, laserprinter, helvetica) _local_print("a"); _local_print("b"); _local_print("c"); #undef _local_print or (mapcar '(lambda (comment) (print comment 5 laserprinter helvetica)) '("a" "b" "c")) or [(a) (b) (c)] {5 laserprinter helvetica print} foreach or ... >> 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. ;-) The device in question is not the disk, but rather, the window. These extra lines contain no semantic information that isn't made obvious by the indentation, and often as much as double the vertical length of the code. The only justifications I can think of are: - They make visual matching easier. But any editor worth its bits blinks matching parens more accurately than you could ever do manually. - Moving blocks of code around tends to be slightly easier. Conceded. I'll put in vertical whitespace where there should be some, but I won't dispense it wastefully. In increasing verbosity, if c if c if c then {s1 then { then s2 s1 { s3} s2 s1 else {s4 s3 s2 s5} } s3 else { } s4 else s4 { } s4 s5 } The rightmost case is common in non-Lispish languages. And is also twice as long, with no significant gain in readability. Note that if I thought the situation justified it, I would insert some white between the clauses. Fortunately, these kinds of transformations are mostly mechanical, and a programmable editor can be taught to make them on the fly. Unfortunately, it is only MOSTLY mechanical, so such transformations might not be perfect. Code is not usually examined in a vacuum. The amount of time required to switch buffers, shuffle printouts, scroll, look up documentation, etc., all contribute to the wholistic merit of a portion of code. Regards, [Ag]