[NIT] Pretty pretting #ifFalse:ifTrue:

Doug Way dway at riskmetrics.com
Wed Nov 21 04:58:08 UTC 2001


Bijan Parsia wrote:
> 
> On Tue, 20 Nov 2001, Doug Way wrote:
> 
> [snip]
> > On the other hand, some might argue that they can impart extra meaning
> > to code they've written by hand-formatting it in a certain way, which
> > should be preserved for all to see.  But that seems bogus to me... it
> > certainly wouldn't outweight the benefits of reading uniformly
> > formatted code.  I'd be curious to see a counterexample claim, though.
> > :)
> [snip]
> 
> Given Dan Ingalls post, I don't really have more much to say about this.
> *But* the point that I was trying to raise is that the current system
> doens't just reformat, it alters the actual code, replacing *certain*
> expressions with their semantic equivalents. In other words, pretty
> printing is decompiling, and decompiling after certain code
> transformations have happened.

Yes, I definitely agree with your point about altering the code.  This
goes along with Richard's definition of pretty-printing, which I agree with.

Switching ifFalse:ifTrue: to ifTrue:ifFalse: also counts as
code-altering, which a pretty-printer shouldn't do.  I also like to use
ifFalse:ifTrue:, when the ifFalse: clause is much shorter than the ifTrue:.

It sounds like we're all pretty much in agreement that the
pretty-printer shouldn't reveal this sort of parse-tree optimizing.  I
haven't tried Henrik's changeset, but maybe it's worth a look.

- Doug Way
  dway at riskmetrics.com




More information about the Squeak-dev mailing list