When clever is stupid

ruby-talk
1

Some time in the past, I wrote a line of code.

It looked like this:

if pu : pu = pu.url.to_s != '' ? pu : nil end

There is sat, working fine, for a long time. Today, I was editing the code, doing a variation on it for a new site.

I came to that line.

I looked at it.

I called it stupid.

Sure, it's concise, but what did I gain by making it so concise over making it so that it was clearly readable a year and a half later?

Not much.

Sometimes clever is good, when there is a reason for it. However, that time, clever was just plain stupid.

Kirk Haines

2

Perhaps it's just not clever enough! :wink: It's concise, but it could be
more concise and maybe a little clearer at the same time:

pu = nil if pu && pu.url.to_s.empty?

... although I think I'd be more inclined to write it out using the
multi-line if form.

Paul.

···

On 01/09/06, khaines@enigo.com <khaines@enigo.com> wrote:

if pu : pu = pu.url.to_s != '' ? pu : nil end
...
Sure, it's concise, but what did I gain by making it so concise over
making it so that it was clearly readable a year and a half later?
...
Sometimes clever is good, when there is a reason for it. However, that
time, clever was just plain stupid.

3

Seeing how it assigns pu to pu (in one case) I would classify that part as redundant :slight_smile:

Here’s my 20% more concise version:

     pu = nil if pu && pu.url.to_s.empty?

···

On 1/9/2006, at 19:37, khaines-at-enigo.com wrote:

[...] It looked like this:

if pu : pu = pu.url.to_s != '' ? pu : nil end

[...] Sure, it's concise [...]

    > concise: giving a lot of information clearly
    > and in a few words; brief but comprehensive

4

khaines@enigo.com wrote:

I came to that line.

I looked at it.

I called it stupid.

Sure, it's concise, but what did I gain by making it so concise over making it so that it was clearly readable a year and a half later?

Here, have a cookie. A Cookie of Clarity. It has extra doses of golf urge repellent.

Usually, the problem is the "clever" solution was stupid since the start. I see nothing clever about just randomly stuffing some logic into as few characters as possible - (ab)using the syntax flexibility makes sense when you can achieve let's say a reordering of the terms that's more natural (not necessarily quick) to read than the more common would be. That example line of code just requires me to keep the whole ternary conditional operator in my head as I try to mentally evaluate the condition.

Ternary operators are inherently evil whenever nested, although a bit more terse in the good term when used as a single expression. Putting the "else" result on a newline and indenting the ? with the : considered sexy, I find it very easy to visually separate the condition and the different results then using the quadrants split up by the operator.

David Vallner

5

khaines@enigo.com wrote:

Some time in the past, I wrote a line of code.

It looked like this:

if pu : pu = pu.url.to_s != '' ? pu : nil end

I wasn't even aware that you can use ":" instead of "then"...

Is this equivalent to your code?

pu = nil if pu && pu.url.to_s == ''

I find it still pretty concise and much easier to read.

Sure, it's concise, but what did I gain by making it so concise over making it so that it was clearly readable a year and a half later?

Not much.

Was there any gain at all?

Sometimes clever is good, when there is a reason for it. However, that time, clever was just plain stupid.

Right.

Kind regards

  robert

6

David Vallner wrote:

Here, have a cookie. A Cookie of Clarity. It has extra doses of golf
urge repellent.

Usually, the problem is the "clever" solution was stupid since the
start. I see nothing clever about just randomly stuffing some logic into
as few characters as possible - (ab)using the syntax flexibility makes
sense when you can achieve let's say a reordering of the terms that's
more natural (not necessarily quick) to read than the more common would
be. That example line of code just requires me to keep the whole ternary
conditional operator in my head as I try to mentally evaluate the
condition.

Ternary operators are inherently evil whenever nested, although a bit
more terse in the good term when used as a single expression. Putting
the "else" result on a newline and indenting the ? with the : considered
sexy, I find it very easy to visually separate the condition and the
different results then using the quadrants split up by the operator.

I'm not a big fan of nested conditionals -- there's usually an elegant
refactoring that can be done when you have them. In fact, I'm not a big
fan of nested anything. :slight_smile:

7

Here, have a cookie. A Cookie of Clarity. It has extra doses of golf urge repellent.

But is it a tasty cookie? Maybe with a little chocolate (preferably dark)? Or maybe some almond and vanilla? Hmmm.

Usually, the problem is the "clever" solution was stupid since the start. I

Yeah. That's my point, using my own stupid code to demonstrate. It was bad code from the very beginning, both because it's not immediately clear what it does and because, as a couple other people demonstrated, it's not even as clever as it could be for all its ugliness. I am sure I felt a moment of self satisfaction when I wrote it, though. A passing thought of, "Yeah, that's great. Look at that." I don't know. Maybe the oxygen level was a little low in my office that day, maybe the winter winds were howling a bit too much, or maybe I had skipped lunch that day. Who knows.

But it sure was a horrible piece of code to come across this morning.

Kirk Haines

···

On Sat, 2 Sep 2006, David Vallner wrote:

8

Ternary operators are inherently evil whenever nested, although a bit
more terse in the good term when used as a single expression.

The one exception I would list is something like a chained comparison.
For example, a JavaScript implementation of the spaceship operator:

result = a>b ? 1 : a<b ? -1 : 0

As with all things, beauty is in the eye of the beholder, but I find
that "readable" and certainly nicer than:

result = if a>b
  1
elsif a<b
  -1
else
  0
end

Especially when chaining fallbacks (like comparing on more than two
values).

9

"The Elements of Programming Style", although written decades
ago, holds up as an excellent guide to general practice. I'd
love to see a version of it (and Perl Best Practices) for Ruby.

-r

···

--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume rdm@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development

10

I like the "case true" idiom here:

result = case true
when a == b: 0
when a < b : 1
when a > b : -1
end

martin

···

On 9/2/06, Phrogz <gavin@refinery.com> wrote:

> Ternary operators are inherently evil whenever nested, although a bit
> more terse in the good term when used as a single expression.

The one exception I would list is something like a chained comparison.
For example, a JavaScript implementation of the spaceship operator:

result = a>b ? 1 : a<b ? -1 : 0

As with all things, beauty is in the eye of the beholder, but I find
that "readable" and certainly nicer than:

result = if a>b
  1
elsif a<b
  -1
else
  0
end

11

I would do that as:

  resul = (a > b ? 1 : (a < b ? -1 : 0))

That's clearer to me, at least.

-austin

···

On 9/1/06, Phrogz <gavin@refinery.com> wrote:

The one exception I would list is something like a chained comparison.
For example, a JavaScript implementation of the spaceship operator:

result = a>b ? 1 : a<b ? -1 : 0

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

12

M. Edward (Ed) Borasky wrote:

I'm not a big fan of nested conditionals -- there's usually an elegant
refactoring that can be done when you have them. In fact, I'm not a big
fan of nested anything. :slight_smile:

With the usual messy codebase to maintain, I thought I was the only one left whose method / function / whatever extraction finger gets itchy around any and all control structures with more than one statement in them...

David Vallner

13

Oops - missed the "javascript" bit.

martin

···

On 9/2/06, Martin DeMello <martindemello@gmail.com> wrote:

On 9/2/06, Phrogz <gavin@refinery.com> wrote:
> The one exception I would list is something like a chained comparison.
> For example, a JavaScript implementation of the spaceship operator:
>
> result = a>b ? 1 : a<b ? -1 : 0

I like the "case true" idiom here:

14

Martin DeMello wrote:

I like the "case true" idiom here:

result = case true
when a == b: 0
when a < b : 1
when a > b : -1
end

martin

Going further OT, but you can omit the "true":

result = case
when a == b: 0
when a < b : 1
when a > b : -1
end

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

15

David Vallner wrote:

With the usual messy codebase to maintain, I thought I was the only one
left whose method / function / whatever extraction finger gets itchy
around any and all control structures with more than one statement in
them...

I take my hat off to you good sir. Would you please kindly illustrate
this to my co-worker? (I've tried, but if it isn't at least three levels
deep it "isn't cool!")

···

--
Posted via http://www.ruby-forum.com/\.

16

I think that's one of the reasons that long-time C, Java, and Fortran
programmers (among others) tend to view languages like Perl and Ruby as
"only a scripting language": the code doesn't look complex enough to be
considered "real programming". The fact you can do the same things with
less code complexity (much of the time) is the salient factor that gets
overlooked.

···

On Sat, Sep 02, 2006 at 10:01:55AM +0900, Daniel Waite wrote:

David Vallner wrote:
> With the usual messy codebase to maintain, I thought I was the only one
> left whose method / function / whatever extraction finger gets itchy
> around any and all control structures with more than one statement in
> them...

I take my hat off to you good sir. Would you please kindly illustrate
this to my co-worker? (I've tried, but if it isn't at least three levels
deep it "isn't cool!")

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"There comes a time in the history of any project when it becomes necessary
to shoot the engineers and begin production." - MacUser, November 1990

17

Daniel Waite wrote:

I take my hat off to you good sir. Would you please kindly illustrate this to my co-worker? (I've tried, but if it isn't at least three levels deep it "isn't cool!")

Try a brick. *duck*

Strangely enough, I had assembly / call processing people to work with on my last project team (in Java), and I actually managed to bend their style to my will over the course of those months. I seem to recall a certain thread about the value of complete novices in a field sometimes yielding surprising results.

(Iwantoneofthose.com stocks styrofoam bricks. I severely need one for the office.)

David Vallner

18

Why does this work?

martin

···

On 9/2/06, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:

Going further OT, but you can omit the "true":

result = case
when a == b: 0
when a < b : 1
when a > b : -1
end

19

While it may have something to do with it, it is, compared to C, “only a scripting language” because you can only use it for a subset of programming problems.

For example you wouldn’t write a parser, compiler, 3D engine, something like zlib, openssl, or similar in Ruby (because of performance), you can’t write device drivers, you can’t interface to a lot of things (w/o writing bindings in, you guessed it, C) etc.

···

On 2/9/2006, at 3:07, Chad Perrin wrote:

I think that's one of the reasons that long-time C, Java, and Fortran
programmers (among others) tend to view languages like Perl and Ruby as
"only a scripting language": the code doesn't look complex enough [...]

20

Going further OT, but you can omit the "true":

result = case
when a == b: 0
when a < b : 1
when a > b : -1
end

Why does this work?

Cause ruby is cool like that? :wink:

There are actually two forms of case, the first being

case x
when y
  ...
when z
  ...
else
  ...
end

which is equivalent to:

if y === x
   ...
elsif z === x
   ...
else
   ...
end

and
case
  when cond1
   ...
  when cond2
   ...
  else
   ...
end

which is equivalent to

if cond1
   ...
elsif cond2
   ...
else
   ...
end

···

On Sep 2, 2006, at 4:45 PM, Martin DeMello wrote:

On 9/2/06, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:

martin