[squeak-dev] Re: Code formatting patterns

Eliot Miranda eliot.miranda at gmail.com
Tue Oct 8 19:58:49 UTC 2013


On Mon, Oct 7, 2013 at 3:01 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 2013-10-06, at 20:25, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> > hence we're left with the war between visual thinkers (rectangular
> blocks) and verbal thinkers (pascal formatting).  just throwing wood on the
> fire ;-)
>
> I very much like rectangular blocks as the general formatting rule; this
> is how Smalltalk code looks "naturally" to me. However, you must *not* put
> a space inside the brackets because then they draw too much attention,
> standing there on their own:
>
>         [this is
>         rectangular]
>

Ian Piumarta and I are anal enough to prefer

        [this is
         rectangular
         and nicely indented]

;-)


> vs
>
>         [ this is not
>         as rectangular ]
>

yuck.  Ugly as sin.  Hate the extra whitespace.  I like asSortedCollection:
[:a :b| a < b], *not* *horrible* [ :a :b |, or even *worse*, [ : a : b |
(argh)... ;-)


>
> There is, however, one case where the rectangular block formatting falls
> short, IMHO. That is when the block is the receiver of a message. For
> those, I still try to make them rectangular, but if that fails to look
> pleasant I occasionally put the closing bracket below the opening one in a
> line of its own, followed by the message.
>

Yes, this is a pain.  In simple cases I'll write

     [some
      code]
        ensure: [more code]

but this all falls in a heap when there;s an on:do: involved. I try then to
do

        [[some
          code]
                        on: SomeException
                        do: [:ex| something]]
                ensure: [more code]

cuz the lining up of the on:do: and the ensure: obscures things horribly:

        [[some
          code]
                on: SomeException
                do: [:ex| something]]
                ensure: [more code]


> Conventional wisdom says in that case one should refactor the method
> because it got too complex, which I agree to if there is a part that makes
> sense as its own method. However, I personally don't like one-off private
> methods just for the sake of simplifying one method. These typically need
> many arguments, have perhaps multiple return values, so the resulting
> complexity is not worth doing it.  Or am I missing something?
>

Nope.  +1.

If it weren't for comments (and comments are /really/ important) we'd have
implemented a parameterised formatted by now that auto-formatted code to
the preferences of the reader and this would all be moot.  But without a
good AI I don't see how to spot and preserve while reformatting multi-line
comments, comments with diagrams in them, etc, etc, etc.
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131008/f2e5e45a/attachment.htm


More information about the Squeak-dev mailing list