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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Tobias Pape

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
Reply | Threaded
Open this post in threaded view
|

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

Chris Muller-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

Bert Freudenberg
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
>




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

Karl Ramberg


On Wed, Jun 1, 2016 at 12:47 PM, Bert Freudenberg <[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).

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 -

Or search could ignore leading colon

Best,
Karl 


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








Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

Chris Muller-3
>> 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,
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 ] ]

It is so much more OO than "textual" formatting like this:

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

I doubt we'll ever bridge the transition from tile programming to text
coding with formatting like this..  :(

I really don't notice any predominant style among different authors of
Squeak, 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.

 - Chris

Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

Chris Muller-3
> formatting standard or style would be counterproductive for the

s/counterproductive/productive

Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

Eliot Miranda-2
In reply to this post by Bert Freudenberg


On Wed, Jun 1, 2016 at 3:47 AM, Bert Freudenberg <[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).

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

+1000
 

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








--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

marcel.taeumel
Eliot Miranda-2 wrote
On Wed, Jun 1, 2016 at 3:47 AM, Bert Freudenberg <[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).
>
> 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”.
>

+1000


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


--
_,,,^..^,,,_
best, Eliot
You saw that code when I made infinite text undo working again. It is in Editor >> #selectWord and #selectWordLeftDelimiters:rightDelimiters:. You cannot just add $':' to the list of delimiters because that would complicate symbol selection. So, the steps would be look for more context whether you want to select "#open:with:" with clicks and also "each" from "...[ :each |..."

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

Bert Freudenberg
In reply to this post by Chris Muller-3

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






smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

Eliot Miranda-2


On Wed, Jun 1, 2016 at 1:45 PM, Bert Freudenberg <[hidden email]> wrote:

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

+1
 

or maybe

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

-1.  Blocks braces should delineate rectangular areas for us visual thinkers.  So it's fine if it fits on one line, but if it fits on two, break to a new line and indent please.
 

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

All to much of it exists in some places I won't illuminate.  Agreed; I find it both horribly ugly and wasteful of screen real estate.
 


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

+1.
 

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

+1.  But having a good formatter which can implement Kent's style guide would be nice.  We're not there yet.
 
I wonder if we should include a précis of Kent;s guide in a workspace window in new releases.  We could put a short guide/cheat sheet in one, and a formatting guide in another.

- Bert -

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

timrowledge
Now I *don’t* like this

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

At least if applied vigourously. When there are *short* statements I’d rather see
  coll do: [:each| statement]
or
coll do:[:each| (condition) ifTrue:[statement]]
etc, keeping as much as possible nicely compact.

I find pretty-print makes code far too ‘tall’ for my taste - oh and hardwrapping comments is really annoying!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Only playing with 51 cards.




Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

Chris Muller-3
In reply to this post by Eliot Miranda-2
> +1.  But having a good formatter which can implement Kent's style guide
> would be nice.  We're not there yet.

Why not give [1] a try?  I've tweaked it to remove the spacing which
you and Bert don't like.  Even though I think its a mistake to remove
this whitespace, we could at least have a pretty-print that is usable
OOTB and based on a known and thought-out rationale that suits
Smalltalk.  Does anyone know the origins of the formatting we have
now?

[1] -- Compiler-cmm.323 in the Inbox.  I believe its at least 90% Kent
Beckian, but there are one or two corner-case bugs I couldn't figure
out how to solve..

Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

Eliot Miranda-2
In reply to this post by timrowledge
Hi Tim,

> On Jun 1, 2016, at 5:42 PM, tim Rowledge <[hidden email]> wrote:
>
> Now I *don’t* like this
>
>>>     coll do:
>>>           [ :each |
>>>           statement1.
>>>           (condition1) ifTrue: [ statement2 ] ]
>
> At least if applied vigourously. When there are *short* statements I’d rather see
>  coll do: [:each| statement]
> or
> coll do:[:each| (condition) ifTrue:[statement]]
> etc, keeping as much as possible nicely compact.

That's just what Kent's style guide recommends.  If the block fits comfortably on one line then by all means put it in one line.  The primary constraint is that the block braces form the top left and bottom right of a rectangle which contains all of the block's text.  So a one line block trivially satisfies that.  The main thing this precludes is attaching the opening brace to the end of an ifTrue:/ifFalse; far to the right of the start of the first line of the block;

    braceAtTheEndOfLine ifTrue: [
         (this isA: #Monstrosity) because:
                blocks are objects not syntax].

> I find pretty-print makes code far too ‘tall’ for my taste - oh and hardwrapping comments is really annoying!

+1 & +1

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- Only playing with 51 cards.
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

Levente Uzonyi
On Thu, 2 Jun 2016, Eliot Miranda wrote:

> Hi Tim,
>
>> On Jun 1, 2016, at 5:42 PM, tim Rowledge <[hidden email]> wrote:
>>
>> Now I *don’t* like this
>>
>>>>     coll do:
>>>>           [ :each |
>>>>           statement1.
>>>>           (condition1) ifTrue: [ statement2 ] ]
>>
>> At least if applied vigourously. When there are *short* statements I’d rather see
>>  coll do: [:each| statement]
>> or
>> coll do:[:each| (condition) ifTrue:[statement]]
>> etc, keeping as much as possible nicely compact.
>
> That's just what Kent's style guide recommends.  If the block fits comfortably on one line then by all means put it in one line.  The primary constraint is that the block braces form the top left and bottom right of a rectangle which contains all of the block's text.  So a one line block trivially satisfies that.  The main thing this precludes is attaching the opening brace to the end of an ifTrue:/ifFalse; far to the right of the start of the first line of the block;
>
>    braceAtTheEndOfLine ifTrue: [
>         (this isA: #Monstrosity) because:
>                blocks are objects not syntax].
This is absolutely personal preference, but I prefer to have blocks have
similar syntax as methods, because that makes it easier to read code.
This means that the first line, which contains the opening bracket and the
argument names, is far less important than what the block does, so it's
perfectly okay to leave it on the previous line.
The indentation tells where the block starts and ends.
What Chris did with the arguments, the additional spaces around variable
names, is a step towards this, because that's exactly how you would write
it, if it were a method.

And methods are objects as well; still you leave a tab at the beginning of
each line, don't you? :)

Levente

>
>> I find pretty-print makes code far too ‘tall’ for my taste - oh and hardwrapping comments is really annoying!
>
> +1 & +1
>
>>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> Useful random insult:- Only playing with 51 cards.
>>
>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

timrowledge
{snipping lots}

> On 02-06-2016, at 8:19 AM, Levente Uzonyi <[hidden email]> wrote:
>
>>
>>   braceAtTheEndOfLine ifTrue: [
>>        (this isA: #Monstrosity) because:
>>               blocks are objects not syntax].
>
> This is absolutely personal preference, but I prefer to have blocks have
> similar syntax as methods, because that makes it easier to read code.
> This means that the first line, which contains the opening bracket and the argument names, is far less important than what the block does, so it's perfectly okay to leave it on the previous line.

So I think you mean
        coll do: [:each|
                statement.
                argument.
                resolution].
… which is pretty much how I prefer things.

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.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IO: Illogical Or



Reply | Threaded
Open this post in threaded view
|

re: Formatting?

Craig Latta

> 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]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

re: Formatting?

Frank Shearar-3
On 2 June 2016 at 10:32, Craig Latta <[hidden email]> wrote:

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

From a _reviewer's_ standpoint, I don't care about the author's personal preference. What is far more important is being able to see not the whitespace changes, but the actual meat of the matter. Review tools typically let you ignore whitespace changes, but since we use email as a review tool, we can make the reviewers' lives far easier if we pick _a_ layout convention, and the old & new versions are printed in the same way.

(Nitpick: the thread's about layout, not syntax. These are not the same, in Smalltalk at least. (C#'s Roslyn parser/compiler/etc library calls this stuff "trivia", for good reason.))

frank
 
-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)





Reply | Threaded
Open this post in threaded view
|

re: Formatting?

David T. Lewis
In reply to this post by Craig Latta
Craig:

Not at all! This is our regularly scheduled annual formatting flame war.
It happens every year at this time, and lasts about three or four weeks
until all of the participants collapse from exhaustion and promise never
to discuss the topic again as long as they live.

;-)

Dave

>
>> 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]
> +31   6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Formatting?

Levente Uzonyi
In reply to this post by timrowledge
On Thu, 2 Jun 2016, tim Rowledge wrote:

> {snipping lots}
>> On 02-06-2016, at 8:19 AM, Levente Uzonyi <[hidden email]> wrote:
>>
>>>
>>>   braceAtTheEndOfLine ifTrue: [
>>>        (this isA: #Monstrosity) because:
>>>               blocks are objects not syntax].
>>
>> This is absolutely personal preference, but I prefer to have blocks have
>> similar syntax as methods, because that makes it easier to read code.
>> This means that the first line, which contains the opening bracket and the argument names, is far less important than what the block does, so it's perfectly okay to leave it on the previous line.
>
> So I think you mean
> coll do: [:each|
> statement.
> argument.
> resolution].
> … which is pretty much how I prefer things.
Close, but not exactly the same:

  coll do: [ :each |
  statement.
  argument.
  resolution ]

If I could change the syntax, I'd make the vertical bar optional, because
that's just a filler with no purpose:

  coll do: [ :each
  statement.
  argument.
  resolution ]

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

Perhaps this discussion will annoy someone enough to volunteer to finally
write a configurable pretty printer. :)

Levente

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: IO: Illogical Or
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

re: Formatting?

timrowledge
In reply to this post by Frank Shearar-3

> On 02-06-2016, at 10:45 AM, Frank Shearar <[hidden email]> wrote:
>
> From a _reviewer's_ standpoint, I don't care about the author's personal preference. What is far more important is being able to see not the whitespace changes, but the actual meat of the matter. Review tools typically let you ignore whitespace changes, but since we use email as a review tool, we can make the reviewers' lives far easier if we pick _a_ layout convention, and the old & new versions are printed in the same way.

Isn’t the ‘prettydiff’ that pretty-prints both versions and diffs those a suitable solution? It seems to work reasonably well to me though I’m sure it could do still more. The obvious advantage is that it splits up code fairly thoroughly and makes it easy to see the actual difference; the disadvantage is sometimes in working out where that maps to in your carefully hand-mangled layout.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
New: It comes in different colors from the previous version.



12