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.
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.
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.
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.
“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.
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!”)
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…
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.)
On Sat, Sep 02, 2006 at 10:01:55AM +0900, Daniel W. wrote:
David V. 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!”)
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.
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
[…]
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.
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.
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.
. . . and I wouldn’t use C or Fortran for certain classes of complex
application programming, either.
There are a lot of things I wouldn’t use Fortran for, although when it
was the only high-level language my colleagues were used to, I did.
But despite its original intent as a systems programming language, I
can’t think of a single application I wouldn’t write in C if that’s what
I was paid to do.
There are tools and programming styles that can make C programming as
easy as programming in a dynamic language like Ruby or Perl or Python.
And the whining about the edit/compile/link/test cycle being less
efficient than the edit/test cycle of a dynamic language I think is just
that – whining. If your complex application is properly modularized,
that’s just not a big deal.
C++, on the other hand, I consider a gross abomination.
I wouldn’t use Java at all, if I could help it, but that’s another
story.
Well … I liked Java at one time well enough to choose it over the
protestations of management for a project … as an excuse to learn the
language. I find Ruby to be a happy blend of all that’s good in Java
(objects, classes, methods, garbage collection) and Perl (regular
expressions, system administration primitives built in, arrays and
hashes, simplified syntax), with a few other nice touches of its own
(lambdas, continuations, open classes).
It’s concise, but it could be
