formatting style
Locked
 
|
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 <[hidden email]>: > 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: .... > > > > |
|
|
In reply to this post by Stéphane Ducasse
+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 <[hidden email]> 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 |
|
|
In reply to this post by Stéphane Ducasse
+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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Stéphane Ducasse
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 <[hidden email]> 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: .... > > > |
|
|
In reply to this post by Lukas Renggli
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
> > On Aug 12, 2011, at 3:58 PM, Lukas Renggli wrote: > >> On 12 August 2011 15:42, Stéphane Ducasse <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>> >> 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 |
|
|
In reply to this post by Nicolas Cellier
On Sat, Aug 13, 2011 at 8:41 AM, Nicolas Cellier <[hidden email]> wrote: 2011/8/13 Stéphane Ducasse <[hidden email]>: +2 raisedTo: SmallInteger maxVal
-- best, Eliot |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |