On 31.05.2016, at 21:26, commits@source.squeak.org 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: Errordo: [ : 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 defaultFontcolor: (Color gray: 0.7)].!
Just curious, why are you adding spaces everywhere? :) Best regards -toibas
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 Das.Linux@gmx.de wrote:
On 31.05.2016, at 21:26, commits@source.squeak.org 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: Errordo: [ : 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 defaultFontcolor: (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 asqueaker@gmail.com 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 Das.Linux@gmx.de wrote:
On 31.05.2016, at 21:26, commits@source.squeak.org 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: Errordo: [ : 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 defaultFontcolor: (Color gray: 0.7)].!Just curious, why are you adding spaces everywhere? :) Best regards -toibas
On Wed, Jun 1, 2016 at 12:47 PM, Bert Freudenberg bert@freudenbergs.de 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 asqueaker@gmail.com 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 Das.Linux@gmx.de wrote:
On 31.05.2016, at 21:26, commits@source.squeak.org 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: Errordo: [ : 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 wantitalic here"
color: (Color gray: 0.7) ]!
in: (self innerBounds insetBy: (5@2 corner: 0@0))
font: textMorph textStyle defaultFontcolor: (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).
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
On 01.06.2016, at 17:46, Chris Muller asqueaker@gmail.com 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 -
On Wed, Jun 1, 2016 at 1:45 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 01.06.2016, at 17:46, Chris Muller asqueaker@gmail.com 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
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; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Only playing with 51 cards.
Hi Tim,
On Jun 1, 2016, at 5:42 PM, tim Rowledge tim@rowledge.org 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; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Only playing with 51 cards.
On Thu, 2 Jun 2016, Eliot Miranda wrote:
Hi Tim,
On Jun 1, 2016, at 5:42 PM, tim Rowledge tim@rowledge.org 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; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Only playing with 51 cards.
{snipping lots}
On 02-06-2016, at 8:19 AM, Levente Uzonyi leves@caesar.elte.hu 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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IO: Illogical Or
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 craig@blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
On 2 June 2016 at 10:32, Craig Latta craig@blackpagedigital.com 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 tosee, 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 craig@blackpagedigital.com +31 6 2757 7177 (SMS ok)
- 1 415 287 3547 (no SMS)
On 02-06-2016, at 10:45 AM, Frank Shearar frank.shearar@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim New: It comes in different colors from the previous version.
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 tosee, 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 craig@blackpagedigital.com +31 6 2757 7177 (SMS ok)
- 1 415 287 3547 (no SMS)
On Thu, 2 Jun 2016, tim Rowledge wrote:
{snipping lots}
On 02-06-2016, at 8:19 AM, Levente Uzonyi leves@caesar.elte.hu 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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IO: Illogical Or
On Thu, Jun 2, 2016 at 9:25 AM, tim Rowledge tim@rowledge.org wrote:
{snipping lots}
On 02-06-2016, at 8:19 AM, Levente Uzonyi leves@caesar.elte.hu 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.
No. That puts the start of the block to the right of the first line of the block. That's not rectangular at all. i.e. "statement" is to the left of "[:each|". It should be
coll do: [:each| statement. argument. resolution].
Here, all the text of the block is included in the recangle formed by "[:each|" and "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.
Understood. Bt Kent gives v good rationale for all elements of his style guide, and one way of avoiding conflicts over formatting is to have and observe as much as possible, and support with tools, a house style.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IO: Illogical Or
On Thu, 2 Jun 2016, Eliot Miranda wrote:
On Thu, Jun 2, 2016 at 9:25 AM, tim Rowledge tim@rowledge.org wrote: {snipping lots} > On 02-06-2016, at 8:19 AM, Levente Uzonyi leves@caesar.elte.hu 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.No. That puts the start of the block to the right of the first line of the block. That's not rectangular at all. i.e. "statement" is to the left of "[:each|". It should be
IMHO it's enough for easy pattern recognition if the statements form a rectangle.
Levente
coll do: [:each| statement. argument. resolution].
Here, all the text of the block is included in the recangle formed by "[:each|" and "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.Understood. Bt Kent gives v good rationale for all elements of his style guide, and one way of avoiding conflicts over formatting is to have and observe as much as possible, and support with tools, a house style.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IO: Illogical Or-- _,,,^..^,,,_ best, Eliot
+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..
On 02.06.2016, at 03:28, Chris Muller asqueaker@gmail.com wrote:
+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..
It’s pretty good.
There shouldn’t be a space before a cascading semicolon though.
I also noticed a bug where sometimes there is no space between multiple args to a block, e.g. in Behavior>>allSubclassesWithLevelDo:startingLevel:.
And it still produces excessively tall code. This:
classAndLevelBlock value: self value: level.
... should be on one line. And if possible
0 to: height - 1 by: 16 do: [:y | ...
should be
0 to: height - 1 by: 16 do: [:y | ...
The rule being something like “if only the last arg is complex, put the message on one line, and the last arg indented by one on the next”.
- Bert -
There shouldn’t be a space before a cascading semicolon though.
That one might be easy to fix..
I also noticed a bug where sometimes there is no space between multiple args to a block, e.g. in Behavior>>allSubclassesWithLevelDo:startingLevel:.
And it still produces excessively tall code. This:
classAndLevelBlock value: self value: level.... should be on one line. And if possible
0 to: height - 1 by: 16 do: [:y | ...should be
0 to: height - 1 by: 16 do: [:y | ...The rule being something like “if only the last arg is complex, put the message on one line, and the last arg indented by one on the next”.
Right, and also, if the block only has "one statement" in it, should go on one line, but IIRC "one statement" from POV of a BlockNode (or whatever it was) could still be a complex multi-line argument (parenthesis, etc.), so I gave up had it always just does this:
envelopes do: [ : e | e duration: seconds ]
instead of all on one line. The Command+[Delete] key helps clean that up. :)
So its been a trade-off for me. I find myself still having to do some manual "clean up" formatting after pretty-printing but, overall, worth it enough for me that I've been running a dirty Compiler package for many years..
On Wed, Jun 1, 2016 at 3:47 AM, Bert Freudenberg bert@freudenbergs.de 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 asqueaker@gmail.com 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 Das.Linux@gmx.de wrote:
On 31.05.2016, at 21:26, commits@source.squeak.org 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: Errordo: [ : 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 wantitalic here"
color: (Color gray: 0.7) ]!
in: (self innerBounds insetBy: (5@2 corner: 0@0))
font: textMorph textStyle defaultFontcolor: (Color gray: 0.7)].!Just curious, why are you adding spaces everywhere? :) Best regards -toibas
Eliot Miranda-2 wrote
On Wed, Jun 1, 2016 at 3:47 AM, Bert Freudenberg <
bert@
> 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 <
asqueaker@
> 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 <
Das.Linux@
> wrote:
On 31.05.2016, at 21:26,
commits@.squeak
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: Errordo: [ : 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 wantitalic here"
color: (Color gray: 0.7) ]!
in: (self innerBounds insetBy: (5@2 corner: 0@0))
font: textMorph textStyle defaultFontcolor: (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
-- View this message in context: http://forum.world.st/Formatting-was-Re-squeak-dev-The-Trunk-ToolBuilder-Mor... Sent from the Squeak - Dev mailing list archive at Nabble.com.
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Muller -
Craig Latta -
David T. Lewis -
Eliot Miranda -
Frank Shearar -
karl ramberg -
Levente Uzonyi -
marcel.taeumel -
tim Rowledge -
Tobias Pape