[Pharo-project] formatting style
I know that you all have your own hyper cool view on formatting. =========================================== Now I would really like that we agree on the minimum put a space after a variable and before := stamp: anObject "stores an author alias and a timestamp" stamp := anObject instead of stamp: anObject "stores an author alias and a timestamp" stamp:= anObject =========================================== Put a space before method argument stamp: anObject "stores an author alias and a timestamp" stamp := anObject instead of stamp:anObject "stores an author alias and a timestamp" stamp := anObject =========================================== Put a space after ifNil: ifTrue: ....
+1 2011/8/12 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I know that you all have your own hyper cool view on formatting.
=========================================== Now I would really like that we agree on the minimum
    put a space after a variable and before :=
stamp: anObject     "stores an author alias and a timestamp"
    stamp := anObject
instead of
stamp: anObject     "stores an author alias and a timestamp"
    stamp:= anObject
=========================================== Put a space before method argument
stamp: anObject     "stores an author alias and a timestamp"
    stamp := anObject
instead of
stamp:anObject     "stores an author alias and a timestamp"
    stamp := anObject
=========================================== Put a space after ifNil: ifTrue: ....
+1 It is of course a delicate subject matter, but I also like spaces inside blocks, inside temporary declarations and after a return, this gives the code more space to breath (hmm ;-), so not inject: thisValue into: binaryBlock "Accumulate a running value associated with evaluating the argument, binaryBlock, with the current value of the argument, thisValue, and the receiver as block arguments. For instance, to sum the numeric elements of a collection, aCollection inject: 0 into: [:subTotal :next | subTotal + next]." |nextValue| nextValue := thisValue. self do: [:each | nextValue := binaryBlock value: nextValue value: each]. ^nextValue but inject: thisValue into: binaryBlock "Accumulate a running value associated with evaluating the argument, binaryBlock, with the current value of the argument, thisValue, and the receiver as block arguments. For instance, to sum the numeric elements of a collection, aCollection inject: 0 into: [:subTotal :next | subTotal + next]." | nextValue | nextValue := thisValue. self do: [ :each | nextValue := binaryBlock value: nextValue value: each ]. ^ nextValue I always think of this a the Seaside style, but I am not sure if that is a correct attribution. Sven On 12 Aug 2011, at 12:04, Stéphane Ducasse wrote:
I know that you all have your own hyper cool view on formatting.
=========================================== Now I would really like that we agree on the minimum
put a space after a variable and before :=
stamp: anObject "stores an author alias and a timestamp"
stamp := anObject
instead of
stamp: anObject "stores an author alias and a timestamp"
stamp:= anObject
=========================================== Put a space before method argument
stamp: anObject "stores an author alias and a timestamp"
stamp := anObject
instead of
stamp:anObject "stores an author alias and a timestamp"
stamp := anObject
=========================================== Put a space after ifNil: ifTrue: ....
I always think of this a the Seaside style, but I am not sure if that is a correct attribution.
Haha, thank you. Actually the refactoring browser formatter with the default settings is quite close to the Seaside style, I just recently submitted some fixes for cascades. The only thing that I don't like about the automatic formatter is how the brackets in multiline blocks are aligned. Anyway, the formatter would style #inject:into: as you suggest. Lukas -- Lukas Renggli www.lukas-renggli.ch
Yes Smalltalk tools register: ;lkl;k;lk;l in: lkl;k;lkl;kl; stef On Aug 12, 2011, at 1:20 PM, Lukas Renggli wrote:
I always think of this a the Seaside style, but I am not sure if that is a correct attribution.
Haha, thank you.
Actually the refactoring browser formatter with the default settings is quite close to the Seaside style, I just recently submitted some fixes for cascades. The only thing that I don't like about the automatic formatter is how the brackets in multiline blocks are aligned. Anyway, the formatter would style #inject:into: as you suggest.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
Hmm, I don't get your example. What I changed is that the formatter does not enforce the useless parenthesis around the receiver of a cascade. Can be disabled though. Also note that there are settings to automatically format code on display and/or accept. I use the "on display" mode often to read ugly code :-) Lukas On 12 August 2011 13:29, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Yes
    Smalltalk tools         register: ;lkl;k;lk;l         in: lkl;k;lkl;kl;
stef On Aug 12, 2011, at 1:20 PM, Lukas Renggli wrote:
I always think of this a the Seaside style, but I am not sure if that is a correct attribution.
Haha, thank you.
Actually the refactoring browser formatter with the default settings is quite close to the Seaside style, I just recently submitted some fixes for cascades. The only thing that I don't like about the automatic formatter is how the brackets in multiline blocks are aligned. Anyway, the formatter would style #inject:into: as you suggest.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
I mean that I prefer
Smalltalk tools register: ;lkl;k;lk;l in: lkl;k;lkl;kl;
over
Smalltalk tools register: ;lkl;k;lk;l in: lkl;k;lkl;kl;
because I do not see fast that the message is register: in: and I guess that you are formatting the way I like but the rb formatter may be wrong because
Smalltalk tools register: ;lkl;k;lk;l
should be more
Smalltalk tools register: ;lkl;k;lk;l
On Aug 12, 2011, at 1:49 PM, Lukas Renggli wrote:
Hmm, I don't get your example.
What I changed is that the formatter does not enforce the useless parenthesis around the receiver of a cascade. Can be disabled though.
Also note that there are settings to automatically format code on display and/or accept. I use the "on display" mode often to read ugly code :-)
Lukas
On 12 August 2011 13:29, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Yes
Smalltalk tools register: ;lkl;k;lk;l in: lkl;k;lkl;kl;
stef On Aug 12, 2011, at 1:20 PM, Lukas Renggli wrote:
I always think of this a the Seaside style, but I am not sure if that is a correct attribution.
Haha, thank you.
Actually the refactoring browser formatter with the default settings is quite close to the Seaside style, I just recently submitted some fixes for cascades. The only thing that I don't like about the automatic formatter is how the brackets in multiline blocks are aligned. Anyway, the formatter would style #inject:into: as you suggest.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
On 12 August 2011 15:42, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I mean that I prefer
Smalltalk tools         register: ;lkl;k;lk;l         in: lkl;k;lkl;kl;
over
Smalltalk tools register: ;lkl;k;lk;l         in: lkl;k;lkl;kl;
because I do not see fast that the message is register: in:
Hmm, I still don't understand your example because the $; has semantic meaning and because the example doesn't even compile :-)
and I guess that you are formatting the way I like but the rb formatter may be wrong because
You can configure after how how many keyword parts (that is probably too low right now) it should print on one line. Also you can tell it how many characters per line you maximally want (used to be 80, I think i changed the default to 100; but probably should be inifite). Lukas
On Aug 12, 2011, at 1:49 PM, Lukas Renggli wrote:
Hmm, I don't get your example.
What I changed is that the formatter does not enforce the useless parenthesis around the receiver of a cascade. Can be disabled though.
Also note that there are settings to automatically format code on display and/or accept. I use the "on display" mode often to read ugly code :-)
Lukas
On 12 August 2011 13:29, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Yes
    Smalltalk tools         register: ;lkl;k;lk;l         in: lkl;k;lkl;kl;
stef On Aug 12, 2011, at 1:20 PM, Lukas Renggli wrote:
I always think of this a the Seaside style, but I am not sure if that is a correct attribution.
Haha, thank you.
Actually the refactoring browser formatter with the default settings is quite close to the Seaside style, I just recently submitted some fixes for cascades. The only thing that I don't like about the automatic formatter is how the brackets in multiline blocks are aligned. Anyway, the formatter would style #inject:into: as you suggest.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
On Aug 12, 2011, at 3:58 PM, Lukas Renggli wrote:
On 12 August 2011 15:42, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I mean that I prefer
Smalltalk tools register: ;lkl;k;lk;l in: lkl;k;lkl;kl;
over
Smalltalk tools register: ;lkl;k;lk;l in: lkl;k;lkl;kl;
because I do not see fast that the message is register: in:
Hmm, I still don't understand your example because the $; has semantic meaning and because the example doesn't even compile :-)
Smalltalk tools register: 'string' in: 'hkjjkhkhjh'
:)
and I guess that you are formatting the way I like but the rb formatter may be wrong because
You can configure after how how many keyword parts (that is probably too low right now) it should print on one line. Also you can tell it how many characters per line you maximally want (used to be 80, I think i changed the default to 100; but probably should be inifite).
I will play with it. I'm really thinking that having a systematic formatting of code within the core would be good.
Lukas
On Aug 12, 2011, at 1:49 PM, Lukas Renggli wrote:
Hmm, I don't get your example.
What I changed is that the formatter does not enforce the useless parenthesis around the receiver of a cascade. Can be disabled though.
Also note that there are settings to automatically format code on display and/or accept. I use the "on display" mode often to read ugly code :-)
Lukas
On 12 August 2011 13:29, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Yes
Smalltalk tools register: ;lkl;k;lk;l in: lkl;k;lkl;kl;
stef On Aug 12, 2011, at 1:20 PM, Lukas Renggli wrote:
I always think of this a the Seaside style, but I am not sure if that is a correct attribution.
Haha, thank you.
Actually the refactoring browser formatter with the default settings is quite close to the Seaside style, I just recently submitted some fixes for cascades. The only thing that I don't like about the automatic formatter is how the brackets in multiline blocks are aligned. Anyway, the formatter would style #inject:into: as you suggest.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
2011/8/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Aug 12, 2011, at 3:58 PM, Lukas Renggli wrote:
On 12 August 2011 15:42, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I mean that I prefer
Smalltalk tools         register: ;lkl;k;lk;l         in: lkl;k;lkl;kl;
over
Smalltalk tools register: ;lkl;k;lk;l         in: lkl;k;lkl;kl;
because I do not see fast that the message is register: in:
Hmm, I still don't understand your example because the $; has semantic meaning and because the  example doesn't even compile :-)
Smalltalk tools         register: 'string'         in: 'hkjjkhkhjh'
:)
and I guess that you are formatting the way I like but the rb formatter may be wrong because
You can configure after how how many keyword parts (that is probably too low right now) it should print on one line. Also you can tell it how many characters per line you maximally want (used to be 80, I think i changed the default to 100; but probably should be inifite).
I will play with it. I'm really thinking that having a systematic formatting of code within the core would be good.
The thing that upsets me most is auto-formatting of literals. 1) the formatter SHALL try to preserve the indenting of array literals A 256 elements table organised in a 16x16 fashion can be legible. A rough 256 element suit is not. 2) the formatter SHALL preserve the base used to specify a number literal If i write 2r1011 it's clearly not my intention to read 11. It's the same for number composing a literal array/byte array In other words, the literals shall better be left unchanged. The second thing that is annoying is that it can become hard to compare code and track evolutions. But this one is just a question of having the right tool to perform the comparison... I always thought that MC, change list and friends should propose an option that simply compares scanned tokens and optionnally ignore comments. Nicolas
Lukas
On Aug 12, 2011, at 1:49 PM, Lukas Renggli wrote:
Hmm, I don't get your example.
What I changed is that the formatter does not enforce the useless parenthesis around the receiver of a cascade. Can be disabled though.
Also note that there are settings to automatically format code on display and/or accept. I use the "on display" mode often to read ugly code :-)
Lukas
On 12 August 2011 13:29, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Yes
    Smalltalk tools         register: ;lkl;k;lk;l         in: lkl;k;lkl;kl;
stef On Aug 12, 2011, at 1:20 PM, Lukas Renggli wrote:
I always think of this a the Seaside style, but I am not sure if that is a correct attribution.
Haha, thank you.
Actually the refactoring browser formatter with the default settings is quite close to the Seaside style, I just recently submitted some fixes for cascades. The only thing that I don't like about the automatic formatter is how the brackets in multiline blocks are aligned. Anyway, the formatter would style #inject:into: as you suggest.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
The thing that upsets me most is auto-formatting of literals.
1) the formatter SHALL try to preserve the indenting of array literals A 256 elements table organised in a 16x16 fashion can be legible. A rough 256 element suit is not. 2) the formatter SHALL preserve the base used to specify a number literal If i write 2r1011 it's clearly not my intention to read 11. It's the same for number composing a literal array/byte array
In other words, the literals shall better be left unchanged.
The second thing that is annoying is that it can become hard to compare code and track evolutions. But this one is just a question of having the right tool to perform the comparison... I always thought that MC, change list and friends should propose an option that simply compares scanned tokens and optionnally ignore comments.
100% with you. Marcus made progress on OPAL and once we have AST in the image (now we have it) we should really invest in bringing the tools to another level. I hope that we will stop cleaning but really defining new tools. Stef
2011/8/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
The thing that upsets me most is auto-formatting of literals.
1) the formatter SHALL try to preserve the indenting of array literals  A 256 elements table organised in a 16x16 fashion can be legible.  A rough 256 element suit is not. 2) the formatter SHALL preserve the base used to specify a number literal  If i write 2r1011 it's clearly not my intention to read 11.  It's the same for number composing a literal array/byte array
In other words, the literals shall better be left unchanged.
The second thing that is annoying is that it can become hard to compare code and track evolutions. But this one is just a question of having the right tool to perform the comparison... I always thought that MC, change list and friends should propose an option that simply compares scanned tokens and optionnally ignore comments.
100% with you. Marcus made progress on OPAL and once we have AST in the image (now we have it) we should really invest in bringing the tools to another level. I hope that we will stop cleaning but really defining new tools.
Stef
IMO a lexical comparison with a Scanner should be enough. Nicolas
On Sat, Aug 13, 2011 at 8:41 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2011/8/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Aug 12, 2011, at 3:58 PM, Lukas Renggli wrote:
On 12 August 2011 15:42, Stéphane Ducasse <stephane.ducasse@inria.fr>
wrote:
I mean that I prefer
Smalltalk tools register: ;lkl;k;lk;l in: lkl;k;lkl;kl;
over
Smalltalk tools register: ;lkl;k;lk;l in: lkl;k;lkl;kl;
because I do not see fast that the message is register: in:
Hmm, I still don't understand your example because the $; has semantic meaning and because the example doesn't even compile :-)
Smalltalk tools register: 'string' in: 'hkjjkhkhjh'
:)
and I guess that you are formatting the way I like but the rb formatter
may be wrong because
You can configure after how how many keyword parts (that is probably too low right now) it should print on one line. Also you can tell it how many characters per line you maximally want (used to be 80, I think i changed the default to 100; but probably should be inifite).
I will play with it. I'm really thinking that having a systematic formatting of code within the core would be good.
The thing that upsets me most is auto-formatting of literals.
1) the formatter SHALL try to preserve the indenting of array literals A 256 elements table organised in a 16x16 fashion can be legible. A rough 256 element suit is not. 2) the formatter SHALL preserve the base used to specify a number literal If i write 2r1011 it's clearly not my intention to read 11. It's the same for number composing a literal array/byte array
In other words, the literals shall better be left unchanged.
+2 raisedTo: SmallInteger maxVal
The second thing that is annoying is that it can become hard to compare code and track evolutions. But this one is just a question of having the right tool to perform the comparison... I always thought that MC, change list and friends should propose an option that simply compares scanned tokens and optionnally ignore comments.
Nicolas
Lukas
On Aug 12, 2011, at 1:49 PM, Lukas Renggli wrote:
Hmm, I don't get your example.
What I changed is that the formatter does not enforce the useless parenthesis around the receiver of a cascade. Can be disabled though.
Also note that there are settings to automatically format code on display and/or accept. I use the "on display" mode often to read ugly code :-)
Lukas
On 12 August 2011 13:29, Stéphane Ducasse <stephane.ducasse@inria.fr>
wrote:
Yes
Smalltalk tools register: ;lkl;k;lk;l in: lkl;k;lkl;kl;
stef On Aug 12, 2011, at 1:20 PM, Lukas Renggli wrote:
I always think of this a the Seaside style, but I am not sure if that is a correct attribution.
Haha, thank you.
Actually the refactoring browser formatter with the default settings is quite close to the Seaside style, I just recently submitted some fixes for cascades. The only thing that I don't like about the automatic formatter is how the brackets in multiline blocks are aligned. Anyway, the formatter would style #inject:into: as you suggest.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
-- best, Eliot
+1 Alexandre On 12 Aug 2011, at 06:04, Stéphane Ducasse wrote:
I know that you all have your own hyper cool view on formatting.
=========================================== Now I would really like that we agree on the minimum
put a space after a variable and before :=
stamp: anObject "stores an author alias and a timestamp"
stamp := anObject
instead of
stamp: anObject "stores an author alias and a timestamp"
stamp:= anObject
=========================================== Put a space before method argument
stamp: anObject "stores an author alias and a timestamp"
stamp := anObject
instead of
stamp:anObject "stores an author alias and a timestamp"
stamp := anObject
=========================================== Put a space after ifNil: ifTrue: ....
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Matches my style. Though prefer no spaces after ^ and around blocks and temps. Really dislike . after last statement too ;-) Sent from my iPhone On 12 Aug 2011, at 11:04, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I know that you all have your own hyper cool view on formatting.
=========================================== Now I would really like that we agree on the minimum
put a space after a variable and before :=
stamp: anObject "stores an author alias and a timestamp"
stamp := anObject
instead of
stamp: anObject "stores an author alias and a timestamp"
stamp:= anObject
=========================================== Put a space before method argument
stamp: anObject "stores an author alias and a timestamp"
stamp := anObject
instead of
stamp:anObject "stores an author alias and a timestamp"
stamp := anObject
=========================================== Put a space after ifNil: ifTrue: ....
participants (7)
-
Alexandre Bergel -
Eliot Miranda -
Gary Chambers -
Lukas Renggli -
Nicolas Cellier -
Stéphane Ducasse -
Sven Van Caekenberghe