Automatic source code formatting bug.

On Thu, 11 Mar 2004 15:04:49 -0500,
Bill Schwab <[hidden email]> wrote:
> Stefan,
>
>> It's not important for the other to understand what's going on here,
>> it's important to show that interfacing a) can be done b) in both
> directions
>> with c) very little effort.
>
> That is excellent advice that doesn't quite fit in my situation, only

:-)

> because we go much further than code samples.  The reality of external
> interfacing should be clear (to anyone who is willing to see it) from the
> systems we have running at present.

Are those systems simple enough so that this is recognizable by a
technical layman? Most of them are really grateful, if you manage
to break things down to a level they can relate to. Even if their
day job is complex mechanics/hydraulics/whatever complex things I
could not understand for all the espresso in their coffee machine,
really "soft" software is hard to grasp.

> The _real_ problem is the "why don't
> you recode that in ..." reaction.

Yeah ... I try to avoid those. If I can't, I usually start making
(naturally) stupid suggestions for their line of work, after which
we get on, more often than not :-)

> I don't think I need to list the reasons
> to leave it in Smalltalk, at least not in this forum :)  Nor do I need to
> explain that the recoded result, if it worked at all, could easily turn out
> to be slower, and certainly less mutable.

Pray tell! And crosspost to c.l.{objects,lisp,c++,java,perl}!

>
> So how did we get from a bug in the parser/formatter to this conversation?

It's mainly because I started picking on some minor point and then tend
to wander off in strange directions ... hey, but guess what, it makes
for great surprises sometimes.

>>
>> another nail in the coffin ... me reading things you did not write :-)
>
> Another word for that is reading between the lines.  As you can see, there
> was something to be found, but not quite what you thought.

OTOH, there might have been something to be found, but not quite what
*you* thought ;->

Communication (or lack thereof) cuts both ways, most of the time.

But it has been a nice conversation, after all.

thanks and g'night,
s.

Bill, everyone,

I think there two questions bundled up here.

One is about whether the RB (or rather, the refactoring engine) should be
reformatting at all.  It seems that I stand alone in thinking that it should
not, and specifically in thinking that it is "wrong" enough not to use the
tool.  Still, judging by the very recent thread in C.L.S (and a few other
comments), that the RB code base has moved on, and that it is now able to
perform (at least) simple refactorings without reformatting.  If that's true
then it is good news for me -- or at least I hope it is.  It depends, among
other factors, on whether OA will be integrating the new code into the shipped
product ?

The second question is: given that the code *is* going to be reformatted, what
is the "correct" way to do it ?  This is nothing to do with preferred layouts,
it's about *why* you want the code to be reformatted, and the range of reasons
seems to be quite wide.  At one end we have Andy's stated preference for just
typing a whole method on one line and letting the RB sort it out, at the other
we have Bill's wish to have as much semantically useful layout, etc, as
possible preserved.  The problem is that it isn't obviously possible to serve
both requirements.

As an example -- *only* as an example -- I like to use column 0 indent as a
"flag" for code that is purely temporary, trace statements and the like, e.g:

aMethod
        | it |
        it := self doSomething.
self assert: [it isKindOf: Whatever].
        it doSomething else.
        ^ self postProcess: it.

Here the lack of indentation makes the assertion stand out so that I remember
to remove it.  I think it's clear that the RB cannot both preserve that kind of
metadata *and* serve Andy's desire to "just type".

Most useful metadata, of course, comes in other forms: e.g. the presence or
absence of a blank line between a comment and the next line of code is almost
universally used to "scope" the comment.

So, it's two (or more) uses for the same tool, and it can't be best for both.
Does anyone have a feeling for how "most" people want to use the RB ?  Or can
the range be covered by the existing configurability ?

Anyway, I'd be happy to chip in with a list of the changes it makes that seem
to me to be most likely to remove useful metadata (I'll have to go back and
check that it's still making the changes I remember).  I'm not sure how to
package such a list, though.  SUnit tests don't seem to fit the bill since they
would most naturally prescribe *exactly* how the output text was supposed to
look, but all we actually want is to be able to say things like:

-------------------
Input:
        "a comment"
        some code.
-------------------
Output: should not introduce blank line between comment and code.
-------------------

and:

-------------------
Input:
        "a comment"

        some code.
-------------------
Output: should preserve blank line between comment and code.
-------------------

And so on.

    -- chris

Chris,

> One is about whether the RB (or rather, the refactoring engine) should be
> reformatting at all.  It seems that I stand alone in thinking that it
should
> not, and specifically in thinking that it is "wrong" enough not to use the
> tool.

You're not alone.  In truth, I wish formatting were optional, and the
reality is that I would probably leave it off.  However, I see great value
in the RB, and would use it (more) provided I could use it w/o doing damage
to my quality control efforts, and find or write a formatter that gets
blocks to look the way I want.  Based on my earlier efforts, I think a
formatter that works to my liking is just a matter of some programming.  The
problem is that the parse tree is not friendly to the comments that are
crucial to me.  When that is a factor, I consider it non-negotiable.


> Still, judging by the very recent thread in C.L.S (and a few other
> comments), that the RB code base has moved on, and that it is now able to
> perform (at least) simple refactorings without reformatting.  If that's
true
> then it is good news for me -- or at least I hope it is.

Ditto!

So far, I've gotten only this far in your post.  I will read the rest later
and reply if "necessary".  However, I didn't want to leave you hanging.  Our
opinions about formatting are _very_ similar.  I have simply identified some
scenarios in which the arguments in favor of the RB win out, because there
is no "comment history" to be lost.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]