Idiom wanted: do-while

ruby-talk
21

Mark Ericson wrote:

Because it's hard for users to tell

  begin <code> end while <cond>

works differently from

  <code> while <cond>

in what ways are they different? Any code examples to show the difference?

Andy already answered, but I thought I'd take my shot at it too.

     begin <code> end while <cond>

is guaranteed to execute <code> at least one time; whereas,

     <code> while <cond>

may never execute <code> because it is exactly equivalent to

     while <cond> <code>

in the same way that

     if <cond> <code>

is equivalent to

     <code> if <cond>

The whole begin/end thing is definitely unnecessary, and can (and frequently does) become a source of confusion; it's a good thing that it's going away. The sooner the better.

--Steve

22

At the risk of sounding like a broken record, I think one of the big advantages of Unit Tests is that they encourage you to code in a manner that is easier to maintain (because it's also easier to test).

As for when someone else jumps in, you show them your test suit and how it works and pray it's catching. :wink: Seriously, you have to worry about you first. The rest of the world takes time. (I did ask in my last job interview if the company covered their software with Unit Tests though! :smiley: )

James Edward Gray II

···

On Dec 14, 2005, at 2:38 AM, Chad Perrin wrote:

On the other hand, coding
in a manner that is in any way less easy to maintain because you know
that the way you write code will ensure that the problem is taken care
of doesn't address the issue of what happens if someone else, with less
ingrained good habits, comes along and takes over.

23

> Hence the need for continuous refactoring. If that's not taking
> place, it management's and/or the developers' fault, not the
> break statement's.

It's definitely not the break statement's fault. It might not be the
developer's or management's either. It might be the fault of the
marketplace, which in turn is nobody's fault -- it is what it is.

If taking the time to understand the code, in preparation for
refactoring, will cause a loss of customers, refactoring can wait
(and unfortunately usually waits until a clean rewrite).

That's unfortunate if you feel that you're in that position (and I can
sympathize, I've been there).

In my mind, refactoring is *part* of code maintenance. When you need
to fix a bug or add functionality, watch for opportunities to
refactor. Refactoring is part of writing the new code, not something
that's applied after the new code is added.

If you're understanding of the code insufficient to make necessary
refactorings while making the change, your understanding of the code
is insufficient to be making the change in the first place.

That being said, I've always tried to refactor when possible. A lot
of times management doesn't even know -- you just rewrite
problematic parts.

Exactly.

By the way, how do you like often maintained, never refactored code
where they have three different variables representing essentially
the same thing, and you need to decide which one to use and which
one to set?

I assume that's a rhetorical question... :slight_smile:

Jacob Fugal

P.S. Thanks for the discussion; I don't mean to be attacking you or
your practices, just evangelizing. :slight_smile:

···

On 12/14/05, Steve Litt <slitt@earthlink.net> wrote:

On Wednesday 14 December 2005 11:24 am, Jacob Fugal wrote: