Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site ccvaxa Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!dual!qantel!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!preece From: preece@ccvaxa.UUCP Newsgroups: net.lang.c Subject: Re: Use of expression values in C Message-ID: <2600007@ccvaxa> Date: Mon, 5-Aug-85 10:43:00 EDT Article-I.D.: ccvaxa.2600007 Posted: Mon Aug 5 10:43:00 1985 Date-Received: Mon, 12-Aug-85 02:03:05 EDT References: <5764@utzoo.UUCP> Lines: 73 Nf-ID: #R:utzoo.UUCP:-576400:ccvaxa:2600007:000:3577 Nf-From: ccvaxa.UUCP!preece Aug 5 09:43:00 1985 > If doing the operation is so much clearer, why do we bother with > subroutines? After all, to figure out what the subroutine does, you've > got to look through its code, but if the operation were done inline, > there would be no problem :-) ---------- Well, there's a qualitative difference between using a subroutine to replace a number of lines of code to perform a complex operation and using a macro with several arguments to replace a more straightforward construction. I don't use embedded assignments because they're more efficient (are they?), I use them because they make sense. The first time I saw them (18 years ago in Dartmouth BASIC) I recognized them as superior chunking agents. Remember chunking? Psychologists tell us that we build separate concepts up into more complex chunks so that we can comprehend more than seven (plus-or-minus two) concepts at a time. Things like embedded assignments and increment operators help [me, at least] build up a larger logical operation than would be possible otherwise. The ONLY thing I object to about them is that there ought to be a more obvious distinction between the assignment and comparison operation symbols. ---------- > Perhaps, the solution to all this would be a procedure. Calling > 'openfile(filename, &fileptr, "r")' gets 'fileptr' set appropriately. > If the open fails a message goes to stderr and 'exit' is called. ---------- We all have our preferences. You dislike embedded assignments, I dislike procedures changing their arguments. I'm currently working on a project that has a huge collection of macro definitions. Without them life would be impossible: they make it possible to do things neatly and transparently. They also make some kinds of problems very hard to find, at which point it becomes necessary to run cpp on the code and see what is really happening. Defining macro expansions and procedures so that they behave in a sensible, consistent, predictable fashion is very, very difficult. ---------- > But, for the record, I consider assignments in 'if' statements > dangerous because I expect 'if' statements to only do tests. ---------- Chacun a son gout. All that really matters are consistency and clarity. If you work within an orderly style and explain what you're doing, your successors will figure it out. ---------- > Trying for micro-efficiencies at the cost of obscure code is > the sign of an immature programmer or a poor typist. ---------- We just differ on what is obscure. I think that the dense but straightforward "if ( (foo=fopen(filename,"r")) == NULL) { ... }" IS clear and simple. I think that hiding it in a macro or breaking it into two lines makes it less clear and more obscure. There's nothing wrong with this kind of disagreement. I wouldn't say either approach indicates, by itself, immaturity or unprofessionalism. ---------- > Run a profiler on your programmer if you think it needs speeding up - > you'll probably find something really gross that slipped by you while > you were trying to construct an 'if' statement with three '++'s > imbedded in it. ---------- This is the absolute truth. If efficiency is the issue, always look for big gains first. Inefficiency is MUCH more likely to come from a broken algorithm than from careless code. On the other hand, DO go back over your 'finished' code and look to see that you've been consistent. The very best thing you can do for future maintenance programmers is to make sure you always do the same thing the same way. -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece