At the O'Reilly ONLamp blog,
chromatic pointed out that we should
"program as if [our] maintenance programmer were not a barely-competent monkey,"
quoting a paragraph from
Mark-Jason Dominus.
Mark was describing the idiocy of programming-by-superstition, where you might put parentheses if you
are unsure of the
order of operations operator precedence (or, to help barely-competent monkeys know the
order precedence),
rather
than re-defining that order as opposed to using them to change the "normal" precedence.
If the parentheses are there to clarify a complex expression, that is one thing (but there are
better ways to do it, such as
using descriptive variable names).
The parentheses add clutter, making the code ever-so-slightly harder to read.
Certainly no one would implement a scanner for string searching when a simple regular
expression would do (I hope, anyway). It would be even more foolish if you did it just because
the next coder to look at the code
might find it easier to understand.
When I first read chromatic's funny phrase, I thought we
should program as if those who
follow us have unintelligible thoughts in their heads. (I still do.) I was looking at it like this:
If I write programs like a monkey would write programs (and I've been known to do such things), the
person following me would need a highly developed brain to
fit
enough of it in his head to be of any use to the code he inherited.
I don't even like to work on some of that old stuff, and I certainly don't understand half of it. Therefore, it would be
better to write the code so that even a monkey can follow it. I'm not talking about concepts
like Mark was talking about. Instead, I'm talking about things like five-line methods, cohesion,
modularity, understandable code, and the sort.
I think both views work - they are just referring to different things.
Maintenance programmers
get dumped on all the time. The least we could do is try to make their jobs easier by not feeding
them crapcode. Maybe a Maintenance Programmer Appreciation Day is in order?
Update: Based on the discussion below, I made a couple of changes to avoid confusion above. Read the comments for more info on that discussion.
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
Just to be a pedant:
Mark does *not* say anything about using parentheses to "redefine the order" of operations because, well, parentheses don't do that.
In the expression a + ( b + c ) the parentheses do not force any particular order of evaluation: any of a, b or c could be evaluated first. In most languages that wouldn't even necessarily force b and c to be added before a is added (precisely because there is no question of associativity here).
It's a fairly common assumption that parentheses somehow affect the order of evaluation - but it's an invalid assumption. Parentheses can only change the associativity of how expressions are combined.
As an example, consider this CFML script:
i = f() - (g() - h());
The order of evaluation is: f(), g(), h() even tho' many people might expect the (g() - h()) part to be evaluated first.
Posted by
Sean Corfield
on Nov 19, 2007 at 06:42 PM UTC - 6 hrs
Sean - you are right, he doesn't mention anything about that. For my part, I probably should have thought a bit longer and chosen better words to get my point across (and also to not make it sound as if I was putting words in his mouth).
What I was trying to get at was that, I imagine Mark (certainly myself) would not choose to use:
a = b*c + b*d
over
a = b * (c + d)
(Probably an optimizing engine would convert the first one to the second, but speaking just from /our/ view)
In that way, the parentheses are "redefining" the order of operation, in that they cause the b to be multiplied by c+d, rather than b*c + d (in the most widely used order of operations). I know it's not really redefining the OOO, since parentheses are part of it, but I couldn't think of a better term.
Does that make sense?
Anyway, thanks for pointing that out - I certainly could have been more clear.
Posted by
Sammy Larbi
on Nov 19, 2007 at 09:17 PM UTC - 6 hrs
"precedence" is the term you are looking for.
In a = b * ( c + d ) the order of evaluation is not affected by the parentheses. You can still evaluate b first, then c (or d) then d (or c) and then c+d and then the result.
a = b * c + b * d is a completely separate expression with different evaluation concerns, including evaluating b twice.
Consider this:
a = f() * ( g() + h() )
compared to:
a = f() * g() + f() * h()
In the first example, f() is called once. In the second example, f() is called twice.
Sorry if I seem to be laboring the point here but this really is an important issue that most people get wrong...
Posted by
Sean Corfield
on Nov 20, 2007 at 01:03 AM UTC - 6 hrs
@Sean,
In practice I can see where this could be an important distinction where the elements are function calls. I can see how both from a debugging viewpoint and from a "unexpected outcomes for functions with side effects" the order of evaluation could be important (although I'd hope most of the time not to be writing code where this kind of order of evaluation issue would impact the outcome).
I'm having a harder time (threading and concurrency issues aside) thinking how the order of evaluation would matter (as opposed to the precedence which clearly does) if these are simple variable calls (which seemed to be Sam's example code) rather than function calls. Could there be any practical case where the order of evaluation would matter within an expression where all of the elements of the expression were simply variable requests as opposed to functions?
Practical questions aside, nice distinction!
Posted by
Peter Bell
on Nov 20, 2007 at 03:52 AM UTC - 6 hrs
Precedence is certainly a better word than order of evaluation, but I was always taught order of operation meant the same as precedence, with OOO being described about how I learned it here:
http://en.wikipedia.org/wiki/Order_of_operationsPrecedence is a better word though, I agree.
Posted by
Sammy Larbi
on Nov 20, 2007 at 09:37 AM UTC - 6 hrs
@Sam, I *believe* Sean is distinguishing between order of operation (which I believe is a synonym for precedence) and order of evaluation which is which of the elements within the expression is evaluated first. Thus if you have a() * (b() + c()) it is possible that function a will be run with the value being stored, then functions b and c. Obviously the outputs of b and c will be summed before being multiplied by function a, but it is possible that function a will actually be called before functions b and c. As I said, other than debugging (if a throws an error) or functions with side effects, I can't think of a practical use of the distinction (unless you write compilers), but it is interesting!
I could however be completely wrong :->
Posted by
Peter Bell
on Nov 20, 2007 at 01:23 PM UTC - 6 hrs
@Peter, yes, "order of operations" is a term from algebra that is not used in computing (because of the possible confusion with "order of evaluation"). Instead precedence is used - since there are many more operators in computer languages and the precedence rules are different in most every language!
I was just trying to make the (important) point that parentheses do not change the order of evaluation - which a lot of people think they do - and thus avoid any confusion for readers who would see "order of operations" in Sammy's post and mistakenly think he meant "order of evaluation".
Posted by
Sean Corfield
on Nov 20, 2007 at 03:53 PM UTC - 6 hrs
I see. We're all on the same page then - I've updated the post to use "operator precedence" instead of "order of operations", and I hope clarified a little better whose mouth the rest came from.
Posted by
Sammy Larbi
on Nov 23, 2007 at 08:46 AM UTC - 6 hrs
