[squeak-dev] Re: Code formatting patterns

Chris Muller asqueaker at gmail.com
Tue Oct 8 21:02:01 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)... ;-)

I guess there's no accounting for taste.  :)

My gripe with [:each | each doSomething] is that word-selection then
includes the colon, which is a pain when you want to Command+h,
Command+g it.  Plus, [: each | each doSomething] is consistent with
method signatures, an anonymous selector.

>> 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.

Right the formatter butchers comments is all the more reason I lean
toward composing methods to expose more meaning.  Auto-formatting is
too valuable to give up.


More information about the Squeak-dev mailing list