Formatting? was: Re: [squeak-dev] The Trunk: ToolBuilder-Morphic-cmm.164.mcz

The predominant style in Squeak historically has been

        coll do: [:each | each do something]

Ken Beck uses that in his “Best Practice Patterns” too. It’s also produced by our formatter (but we rarely use that because it introduces weird line breaks).

I prefer this style because it seems to be most readable.

I agree with Chris about selectability, but I’d rather fix our double-click selection logic than make the code look weird. Double-clicking on “:foo” should only select “foo”.

- Bert -

> On 31.05.2016, at 23:58, Chris Muller <[hidden email]> wrote:
>
> By "everywhere" I assume you mean the ones just inside my brackets?
> When block arguments are written without a space between the colon and
> variable name, like this:
>
>   coll do: [:each|each do something]
>
> then I can't simply double-click the "each" declaration and then use
> Cmd+g to find further occurrences, because double-clicking it also
> selects the colon.
>
> So, I could write:
>
>    coll do: [: each|each do something]
>
> but it looks strange to me.
>
> But also for easier expression editing.  With no space, it is harder
> to select the inner expression via double clicking just inside the
> opening bracket; because a space there affords the user more width to
> hit the expression than the narrow colon.
>
> This effect can be verified on a computer with touch pad with
> **separate buttons** (e.g., able to double-click without moving the
> mouse even one pixel).  1) put a space there, 2) place mouse about
> halfway into width of the space.  3) Without touching touch pad,
> double-click to ensure expression is selected.  4) Now single-click to
> deselect expression.  5) Now press [Delete] to delete the space.  6)
> Without touching touch pad, again double-click in the exact same spot.
> The colon is selected instead of the expression.
>
> On Tue, May 31, 2016 at 4:42 PM, Tobias Pape <[hidden email]> wrote:
>>
>> On 31.05.2016, at 21:26, [hidden email] wrote:
>>
>>
>>> Item was changed:
>>> ----- Method: PluggableTextMorphPlus>>drawBalloonTextOn: (in category 'drawing') -----
>>> + drawBalloonTextOn: aCanvas
>>> - drawBalloonTextOn: aCanvas
>>>      "Show balloon text in the text morph if it has no contents."
>>> +     textMorph contents ifNotEmpty: [ ^ self ].
>>> +     ([ self balloonText ]
>>> +             on: Error
>>> +             do: [ : err | 'error in balloonText' ]) ifNotNil:
>>> +             [ : text | aCanvas
>>> -
>>> -     textMorph contents ifNotEmpty: [^ self].
>>> -
>>> -     self balloonText ifNotNil: [:text |
>>> -             aCanvas
>>>                      drawString: text
>>> +                     in: (self innerBounds insetBy: (5 @ 2 corner: 0 @ 0))
>>> +                     font: textMorph textStyle defaultFont "I want italic here"
>>> +                     color: (Color gray: 0.7) ]!
>>> -                     in: (self innerBounds insetBy: (5@2 corner: 0@0))
>>> -                     font: textMorph textStyle defaultFont
>>> -                     color: (Color gray: 0.7)].!
>>
>> Just curious, why are you adding spaces everywhere?
>> :)
>> Best regards
>>        -toibas
>

The predominant style in Squeak historically has been

        coll do: [:each | each do something]

Ken Beck uses that in his “Best Practice Patterns” too. It’s also produced by our formatter (but we rarely use that because it introduces weird line breaks).

I prefer this style because it seems to be most readable.

I agree with Chris about selectability, but I’d rather fix our double-click selection logic than make the code look weird. Double-clicking on “:foo” should only select “foo”.

- Bert -


> On 31.05.2016, at 23:58, Chris Muller <[hidden email]> wrote:
>
> By "everywhere" I assume you mean the ones just inside my brackets?
> When block arguments are written without a space between the colon and
> variable name, like this:
>
>   coll do: [:each|each do something]
>
> then I can't simply double-click the "each" declaration and then use
> Cmd+g to find further occurrences, because double-clicking it also
> selects the colon.
>
> So, I could write:
>
>    coll do: [: each|each do something]
>
> but it looks strange to me.
>
> But also for easier expression editing.  With no space, it is harder
> to select the inner expression via double clicking just inside the
> opening bracket; because a space there affords the user more width to
> hit the expression than the narrow colon.
>
> This effect can be verified on a computer with touch pad with
> **separate buttons** (e.g., able to double-click without moving the
> mouse even one pixel).  1) put a space there, 2) place mouse about
> halfway into width of the space.  3) Without touching touch pad,
> double-click to ensure expression is selected.  4) Now single-click to
> deselect expression.  5) Now press [Delete] to delete the space.  6)
> Without touching touch pad, again double-click in the exact same spot.
> The colon is selected instead of the expression.
>
> On Tue, May 31, 2016 at 4:42 PM, Tobias Pape <[hidden email]> wrote:
>>
>> On 31.05.2016, at 21:26, [hidden email] wrote:
>>
>>
>>> Item was changed:
>>> ----- Method: PluggableTextMorphPlus>>drawBalloonTextOn: (in category 'drawing') -----
>>> + drawBalloonTextOn: aCanvas
>>> - drawBalloonTextOn: aCanvas
>>>      "Show balloon text in the text morph if it has no contents."
>>> +     textMorph contents ifNotEmpty: [ ^ self ].
>>> +     ([ self balloonText ]
>>> +             on: Error
>>> +             do: [ : err | 'error in balloonText' ]) ifNotNil:
>>> +             [ : text | aCanvas
>>> -
>>> -     textMorph contents ifNotEmpty: [^ self].
>>> -
>>> -     self balloonText ifNotNil: [:text |
>>> -             aCanvas
>>>                      drawString: text
>>> +                     in: (self innerBounds insetBy: (5 @ 2 corner: 0 @ 0))
>>> +                     font: textMorph textStyle defaultFont "I want italic here"
>>> +                     color: (Color gray: 0.7) ]!
>>> -                     in: (self innerBounds insetBy: (5@2 corner: 0@0))
>>> -                     font: textMorph textStyle defaultFont
>>> -                     color: (Color gray: 0.7)].!
>>
>> Just curious, why are you adding spaces everywhere?
>> :)
>> Best regards
>>        -toibas
>

> On 01.06.2016, at 17:46, Chris Muller <[hidden email]> wrote:
>
>>> The predominant style in Squeak historically has been
>>>
>>>        coll do: [:each | each do something]
>>>
>>> Ken Beck uses that in his “Best Practice Patterns” too. It’s also produced
>>> by our formatter (but we rarely use that because it introduces weird line
>>> breaks).
>
> Actually, Kent Beck advocates a Rectangular Block formatting pattern,

I was mostly talking about the issue at hand, namely, whether to put spaces inside of the brackets. Which he does not do.

This is (not entirely by coincidence) the typographical convention in English, too.

That’s why I prefer it, independent of rectangular blocks or not.

> which is NOT produced by our formatter, unless you merge
> Compiler-cmm.179 (which I've just recopied to the Inbox).  I wasn't
> successful in convincing the community to adopt it six years ago.
>
> Besides the reasons already documented by Kents pattern, I like RB
> because it presents a semi-"tiled" view of the code similar to
> Scratch, but with textual, rather than graphical, tiles.  Like this:
>
>      coll do:
>            [ :each |
>            statement1.
>            (condition1) ifTrue: [ statement2 ] ]
>

I’d write it Kent Beck-style, namely


    coll do:
           [:each |
           statement1.
           (condition1) ifTrue: [statement2]]

or maybe

    coll do: [:each |
           statement1.
           (condition1) ifTrue: [statement2]]

> It is so much more OO than "textual" formatting like this:
>
>      coll do: [ :each |
>             statement1.
>             (condition1) ifTrue: [
>                    statement2.
>             ]
>      ]

Agreed. I don’t think I’ve seen much of this style in Squeak. It’s ugly.

> I really don't notice any predominant style among different authors of
> Squeak,

I do. Anything that’s not written in that style looks jarring to me. Like Andreas’ habit of omitting the space between a keyword message and a block (ifTrue:[foo]).

> and I don't think attempting to establish any kind of
> formatting standard or style would be counterproductive for the
> community (not that anyone is suggesting that).  Instead, its probably
> best to let our individual imaginations flow the way they do, and let
> the IDE take care of each of us individually.  Methods can be quickly
> and easily formatted on access and/or save.  However, I do recommend,
> if one is only changing only one or two lines of a longer method, they
> should try to maintain the prior author's format.  Also, never submit
> a change to trunk that ONLY changes the formatting of a method,
> please.

IMHO readability suffers wth mixed styles. Be creative in your coding, not in your formatting. I think it would be a good idea to adopt a style guide. Beck’s would be a good starting point.

- Bert -

> We should be very careful about discussing this. I don’t think
> anything causes more annoyance, hard feeling, lost friendships,
> broken communities, lost projects and global war than syntactic
> debates.

     So true. The environment should show everyone what they want to
see, with the original material as an option. Arguing about these
personal preferences is implicitly accepting a broken environment. This
thread is a bad sign. :)

-C

--
Craig Latta
Black Page Digital
Amsterdam
[hidden email]
<a href="tel:%2B31%20%20%206%202757%207177" value="+31627577177">+31 6 2757 7177 (SMS ok)
<a href="tel:%2B%201%20415%20%20287%203547" value="+14152873547">+ 1 415 287 3547 (no SMS)