When clever is stupid

[khaines]

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

 

[Paul Battley]

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.

Perhaps it's just not clever enough! ;-) 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.

 

[Allan Odgaard]

[...] It looked like this:

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

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

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

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

Here=92s my 20% more concise version:

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

 

[David Vallner]

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

 

[M. Edward (Ed) Borasky]

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.

 

[Phrogz]

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).

 

[khaines]

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

 

[Rich Morin]

"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 (e-mail address removed)
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development

 

[Martin DeMello]

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

I like the "case true" idiom here:

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

martin

 

[Martin DeMello]

I like the "case true" idiom here:

Oops - missed the "javascript" bit.

martin

 

[Austin Ziegler]

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 would do that as:

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

That's clearer to me, at least.

-austin

 

[Joel VanderWerf]

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

 

[David Vallner]

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.

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

 

[Daniel Waite]

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!")

 

[Chad Perrin]

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!")

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.

 

[David Vallner]

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

 

[Allan Odgaard]

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=20=20
Ruby as
"only a scripting language": the code doesn't look complex enough=20=20
[...]

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

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

 

[M. Edward (Ed) Borasky]

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

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 a= s
"only a scripting language": the code doesn't look complex enough [...=

]
=20
While it may have something to do with it, it is, compared to C, =93onl= y a
scripting language=94 because you can only use it for a subset of
programming problems.
=20
For example you wouldn=92t write a parser, compiler, 3D engine, somethi= ng
like zlib, openssl, or similar in Ruby (because of performance), you
can=92t write device drivers, you can=92t interface to a lot of things = (w/o
writing bindings in, you guessed it, C) etc.
=20
=20
=20
=20

You can't or shouldn't really do those things in Java or Fortran either.
C was a *systems* programming language first, and only evolved into an
application programming language later. It was designed for writing
operating systems and compilers and text processing tools. It was almost
15 years before C compilers were competitive with Fortran compilers for
number crunching.

 

[Chad Perrin]

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

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

..]
=20
While it may have something to do with it, it is, compared to C, =E2=80= =9Conly a
scripting language=E2=80=9D because you can only use it for a subset = of
programming problems.
=20
For example you wouldn=E2=80=99t write a parser, compiler, 3D engine,= something
like zlib, openssl, or similar in Ruby (because of performance), you
can=E2=80=99t write device drivers, you can=E2=80=99t interface to a = lot of things (w/o
writing bindings in, you guessed it, C) etc.
=20

You can't or shouldn't really do those things in Java or Fortran either=

 

[Robert Klemme]

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