[Pharo-project] about code formatting in pharo
Hi guys I would like to build a set of canonical code formatting convention for Pharo. I need your help. Now take time before replying :) I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. Once we agree I would like to define a wiki page. **Space after : rule ============= for example I would like to always have a space after a : classes := Smalltalk allClasses select:[:aClass| (aClass class includesSelector: #cleanUp) or:[aClass class includesSelector: #cleanUp:] ]. -> classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:] ]. **Block arg rule ============= Do we want a space before and after block arg Smalltalk allClasses select: [:aClass :method| -> Smalltalk allClasses select: [ :aClass :method | ** selector or block indented compared to receiver ======================================= Finally do we follow kent block ideas? classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:] ]. -> classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:]]. Stef
I would use a formatter, like this you can make it really consistent. The RBConfigurableFormatter is pretty good in that, the only thing I don't like is the placing of the square brackets. I should look into fixing that, otherwise it formats exactly the way I would format myself (and in the way you propose). Lukas On 28 February 2010 10:36, stephane ducasse <stephane.ducasse@free.fr> wrote:
Hi guys
I would like to build a set of canonical code formatting convention for Pharo. I need your help. Now take time before replying :) I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. Once we agree I would like to define a wiki page.
**Space after : rule ============= for example I would like to always have a space after a :
classes := Smalltalk allClasses select:[:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or:[aClass class includesSelector: #cleanUp:] Â Â Â ].
->
classes := Smalltalk allClasses select: [:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] Â Â Â ].
**Block arg rule ============= Do we want a space before and after block arg
Smalltalk allClasses select: [:aClass :method|
-> Smalltalk allClasses select: [ :aClass :method |
** selector or block indented compared to receiver =======================================
Finally do we follow kent block ideas?
classes := Smalltalk allClasses select: [:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] Â Â Â ].
-> classes := Smalltalk allClasses             select: [:aClass| (aClass class includesSelector: #cleanUp)                             or: [aClass class includesSelector: #cleanUp:]].
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Lukas do you have some code samples. Something that I particularly hate is the following self bla ifTrue: [ ... ] ifFalse: [ ... ] That is see in the code. I want self bla ifTrue: [ ... ] ifFalse: [ ... ]
I would use a formatter, like this you can make it really consistent. The RBConfigurableFormatter is pretty good in that, the only thing I don't like is the placing of the square brackets. I should look into fixing that, otherwise it formats exactly the way I would format myself (and in the way you propose).
I would really like to play with the idea of automatic formatting to see how it goes. Stef
Lukas
On 28 February 2010 10:36, stephane ducasse <stephane.ducasse@free.fr> wrote:
Hi guys
I would like to build a set of canonical code formatting convention for Pharo. I need your help. Now take time before replying :) I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. Once we agree I would like to define a wiki page.
**Space after : rule ============= for example I would like to always have a space after a :
classes := Smalltalk allClasses select:[:aClass| (aClass class includesSelector: #cleanUp) or:[aClass class includesSelector: #cleanUp:] ].
->
classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:] ].
**Block arg rule ============= Do we want a space before and after block arg
Smalltalk allClasses select: [:aClass :method|
-> Smalltalk allClasses select: [ :aClass :method |
** selector or block indented compared to receiver =======================================
Finally do we follow kent block ideas?
classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:] ].
-> classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:]].
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
A few examples: Object>>perform: selector orSendTo: otherTarget "If I wish to intercept and handle selector myself, do it; else send it to otherTarget" ^ (self respondsTo: selector) ifTrue: [ self perform: selector ] ifFalse: [ otherTarget perform: selector ] Object>>doesNotUnderstand: aMessage "Handle the fact that there was an attempt to send the given message to the receiver but the receiver does not understand this message (typically sent from the machine when a message is sent to the receiver and no method is defined for that selector)." "Testing: (3 activeProcess)" "fixed suggested by Eliot miranda to make sure [Object new blah + 1]  on: MessageNotUnderstood  do: [:e | e resume: 1] does not loop indefinitively" | exception resumeValue | (exception := MessageNotUnderstood new) message: aMessage; receiver: self. resumeValue := exception signal. ^ exception reachedDefaultHandler ifTrue: [ aMessage sentTo: self ] ifFalse: [ resumeValue ] Below is an example that shows the placement of block brackets with multiline blocks. I would like to change that so that the brackets are placed on the line above (that's in my opinion the only major flaw in the automatic formatting), unfortunately I haven't found the time to do this: Object>>copyFrom: anotherObject "Copy to myself all instance variables I have in common with anotherObject. This is dangerous because it ignores an object's control over its own inst vars. " <primitive: 168> | mine his | mine := self class allInstVarNames. his := anotherObject class allInstVarNames. 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ] Object>>longPrintStringLimitedTo: aLimitValue "Answer a String whose characters are a description of the receiver." | str | str := String streamContents: [ :aStream | self longPrintOn: aStream limitedTo: aLimitValue indent: 0 ]. "Objects without inst vars should return something" ^ str isEmpty ifTrue: [ self printString , String cr ] ifFalse: [ str ] On 28 February 2010 10:58, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Lukas do you have some code samples. Something that I particularly hate is the following
    self bla ifTrue: [         ...
    ] ifFalse: [         ...     ]
That is see in the code.
I want     self bla         ifTrue: [ ...                     ]         ifFalse: [             ...       ]
I would use a formatter, like this you can make it really consistent. The RBConfigurableFormatter is pretty good in that, the only thing I don't like is the placing of the square brackets. I should look into fixing that, otherwise it formats exactly the way I would format myself (and in the way you propose).
I would really like to play with the idea of automatic formatting to see how it goes.
Stef
Lukas
On 28 February 2010 10:36, stephane ducasse <stephane.ducasse@free.fr> wrote:
Hi guys
I would like to build a set of canonical code formatting convention for Pharo. I need your help. Now take time before replying :) I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. Once we agree I would like to define a wiki page.
**Space after : rule ============= for example I would like to always have a space after a :
classes := Smalltalk allClasses select:[:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or:[aClass class includesSelector: #cleanUp:] Â Â Â ].
->
classes := Smalltalk allClasses select: [:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] Â Â Â ].
**Block arg rule ============= Do we want a space before and after block arg
Smalltalk allClasses select: [:aClass :method|
-> Smalltalk allClasses select: [ :aClass :method |
** selector or block indented compared to receiver =======================================
Finally do we follow kent block ideas?
classes := Smalltalk allClasses select: [:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] Â Â Â ].
-> classes := Smalltalk allClasses             select: [:aClass| (aClass class includesSelector: #cleanUp)                             or: [aClass class includesSelector: #cleanUp:]].
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Looks good to me If one day we get a cooler one we could get
self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ]
self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ] self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ]
Object>>longPrintStringLimitedTo: aLimitValue "Answer a String whose characters are a description of the receiver."
| str | str := String streamContents: [ :aStream | self longPrintOn: aStream limitedTo: aLimitValue indent: 0 ]. "Objects without inst vars should return something" ^ str isEmpty ifTrue: [ self printString , String cr ] ifFalse: [ str ]
I would love to have it like that ;-D Object>>longPrintStringLimitedTo: aLimitValue "Answer a String whose characters are a description of the receiver." | str | str := String streamContents: [ :aStream | self longPrintOn: aStream limitedTo: aLimitValue indent: 0 ]. "Objects without inst vars should return something" ^ str isEmpty ifTrue: [ self printString , String cr ] ifFalse: [ str ]
On 28 February 2010 11:58, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Lukas do you have some code samples. Something that I particularly hate is the following
    self bla ifTrue: [         ...
    ] ifFalse: [         ...     ]
That is see in the code.
I want     self bla         ifTrue: [ ...                     ]         ifFalse: [             ...       ]
+1 But, if there is only single block, i usually typing: self bla ifTrue: [ code. code. ] also i'm usually putting closing ' ] ' at new line, but indented relatively to receiver, not like: self bla ifTrue: [ code. code. ] Also, if statement ends with ']' , i adding a blank like at the end: self bla ifTrue: [ code. ]. self bla ifTrue: [ code. ].
I would use a formatter, like this you can make it really consistent. The RBConfigurableFormatter is pretty good in that, the only thing I don't like is the placing of the square brackets. I should look into fixing that, otherwise it formats exactly the way I would format myself (and in the way you propose).
I would really like to play with the idea of automatic formatting to see how it goes.
Stef
Lukas
On 28 February 2010 10:36, stephane ducasse <stephane.ducasse@free.fr> wrote:
Hi guys
I would like to build a set of canonical code formatting convention for Pharo. I need your help. Now take time before replying :) I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. Once we agree I would like to define a wiki page.
**Space after : rule ============= for example I would like to always have a space after a :
classes := Smalltalk allClasses select:[:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or:[aClass class includesSelector: #cleanUp:] Â Â Â ].
->
classes := Smalltalk allClasses select: [:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] Â Â Â ].
**Block arg rule ============= Do we want a space before and after block arg
Smalltalk allClasses select: [:aClass :method|
-> Smalltalk allClasses select: [ :aClass :method |
** selector or block indented compared to receiver =======================================
Finally do we follow kent block ideas?
classes := Smalltalk allClasses select: [:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] Â Â Â ].
-> classes := Smalltalk allClasses             select: [:aClass| (aClass class includesSelector: #cleanUp)                             or: [aClass class includesSelector: #cleanUp:]].
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
But, if there is only single block, i usually typing: self bla ifTrue: [ code. code. ] Yes I see I would prefer self bla ifTrue: [ code. code. ] for me I try
self bla ifTrue: [ code ].
or self bla ifTrue: [ code. code.] but I'm not happy because tabbing does not work to align the last line. So any ideas. I have to reread the kent book. Stef
also i'm usually putting closing ' ] ' at new line, but indented relatively to receiver, not like:
self bla ifTrue: [ code. code. ]
Also, if statement ends with ']' , i adding a blank like at the end:
self bla ifTrue: [ code. ].
self bla ifTrue: [ code. ].
I would use a formatter, like this you can make it really consistent. The RBConfigurableFormatter is pretty good in that, the only thing I don't like is the placing of the square brackets. I should look into fixing that, otherwise it formats exactly the way I would format myself (and in the way you propose).
I would really like to play with the idea of automatic formatting to see how it goes.
Stef
Lukas
On 28 February 2010 10:36, stephane ducasse <stephane.ducasse@free.fr> wrote:
Hi guys
I would like to build a set of canonical code formatting convention for Pharo. I need your help. Now take time before replying :) I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. Once we agree I would like to define a wiki page.
**Space after : rule ============= for example I would like to always have a space after a :
classes := Smalltalk allClasses select:[:aClass| (aClass class includesSelector: #cleanUp) or:[aClass class includesSelector: #cleanUp:] ].
->
classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:] ].
**Block arg rule ============= Do we want a space before and after block arg
Smalltalk allClasses select: [:aClass :method|
-> Smalltalk allClasses select: [ :aClass :method |
** selector or block indented compared to receiver =======================================
Finally do we follow kent block ideas?
classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:] ].
-> classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:]].
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 28 February 2010 12:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
But, if there is only single block, i usually typing:
self bla ifTrue: [ Â code. Â code. Â ]
Yes I see I would prefer
self bla ifTrue: [ Â code. Â code. ]
for me I try
self bla ifTrue: [ code ].
yes, one-liner is ok, but only if its short. The most disguising thing in formatting an exception handling code: runTest: aSelector | actualResult expectedResult | [ self logTest: aSelector; clearLog; perform: aSelector ] on: MyTestError do: [ :ex | self log: 'Unhandled Exception'. ex return: nil ]. as you can see, its a bit hard to quickly determine, where ends one block and starts another one. That's why i'm always putting ' ] ' at the next line, and align its indentation to be the same as in opening brace: [ self logTest: aSelector; clearLog; perform: aSelector ] on: MyTestError do: [ :ex | self log: 'Unhandled Exception'. ex return: nil ]. do you agree that this one is much more readable?
or self bla     ifTrue: [ code.          code.]
but I'm not happy because tabbing does not work to align the last line. So any ideas. I have to reread the kent book.
Stef
also i'm usually putting closing ' ] ' at new line, but indented relatively to receiver, not like:
self bla ifTrue: [ Â Â code. Â Â code. ]
Also, if statement ends with ']' , i adding a blank like at the end:
self bla ifTrue: [ Â Â code. Â ].
self bla ifTrue: [ Â Â code. Â ].
I would use a formatter, like this you can make it really consistent. The RBConfigurableFormatter is pretty good in that, the only thing I don't like is the placing of the square brackets. I should look into fixing that, otherwise it formats exactly the way I would format myself (and in the way you propose).
I would really like to play with the idea of automatic formatting to see how it goes.
Stef
Lukas
On 28 February 2010 10:36, stephane ducasse <stephane.ducasse@free.fr> wrote:
Hi guys
I would like to build a set of canonical code formatting convention for Pharo. I need your help. Now take time before replying :) I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. Once we agree I would like to define a wiki page.
**Space after : rule ============= for example I would like to always have a space after a :
classes := Smalltalk allClasses select:[:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or:[aClass class includesSelector: #cleanUp:] Â Â Â ].
->
classes := Smalltalk allClasses select: [:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] Â Â Â ].
**Block arg rule ============= Do we want a space before and after block arg
Smalltalk allClasses select: [:aClass :method|
-> Smalltalk allClasses select: [ :aClass :method |
** selector or block indented compared to receiver =======================================
Finally do we follow kent block ideas?
classes := Smalltalk allClasses select: [:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] Â Â Â ].
-> classes := Smalltalk allClasses             select: [:aClass| (aClass class includesSelector: #cleanUp)                             or: [aClass class includesSelector: #cleanUp:]].
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns". According to these rules I would format the following example: --------------- 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. --------------- as: --------------- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. --------------- Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me. Cheers, Adrian On Feb 28, 2010, at 12:47 , Igor Stasenko wrote:
On 28 February 2010 12:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
But, if there is only single block, i usually typing:
self bla ifTrue: [ code. code. ]
Yes I see I would prefer
self bla ifTrue: [ code. code. ]
for me I try
self bla ifTrue: [ code ].
yes, one-liner is ok, but only if its short.
The most disguising thing in formatting an exception handling code:
runTest: aSelector
| actualResult expectedResult | [ self logTest: aSelector; clearLog; perform: aSelector ] on: MyTestError do: [ :ex | self log: 'Unhandled Exception'. ex return: nil ].
as you can see, its a bit hard to quickly determine, where ends one block and starts another one. That's why i'm always putting ' ] ' at the next line, and align its indentation to be the same as in opening brace:
[ self logTest: aSelector; clearLog; perform: aSelector ] on: MyTestError do: [ :ex | self log: 'Unhandled Exception'. ex return: nil ].
do you agree that this one is much more readable?
or self bla ifTrue: [ code. code.]
but I'm not happy because tabbing does not work to align the last line. So any ideas. I have to reread the kent book.
Stef
also i'm usually putting closing ' ] ' at new line, but indented relatively to receiver, not like:
self bla ifTrue: [ code. code. ]
Also, if statement ends with ']' , i adding a blank like at the end:
self bla ifTrue: [ code. ].
self bla ifTrue: [ code. ].
I would use a formatter, like this you can make it really consistent. The RBConfigurableFormatter is pretty good in that, the only thing I don't like is the placing of the square brackets. I should look into fixing that, otherwise it formats exactly the way I would format myself (and in the way you propose).
I would really like to play with the idea of automatic formatting to see how it goes.
Stef
Lukas
On 28 February 2010 10:36, stephane ducasse <stephane.ducasse@free.fr> wrote:
Hi guys
I would like to build a set of canonical code formatting convention for Pharo. I need your help. Now take time before replying :) I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. Once we agree I would like to define a wiki page.
**Space after : rule ============= for example I would like to always have a space after a :
classes := Smalltalk allClasses select:[:aClass| (aClass class includesSelector: #cleanUp) or:[aClass class includesSelector: #cleanUp:] ].
->
classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:] ].
**Block arg rule ============= Do we want a space before and after block arg
Smalltalk allClasses select: [:aClass :method|
-> Smalltalk allClasses select: [ :aClass :method |
** selector or block indented compared to receiver =======================================
Finally do we follow kent block ideas?
classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:] ].
-> classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:]].
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian, Horrible is an understatement :) Your version is a big improvement. I frequently put ending brackets on their own line with indentation to aid in matching, but not always. I do not (much) care what conventions the benevolent dictators select for Pharo, but I **do** care that it not be forced on my code that I retain for my own use. There should be ways to compile, export and load code and packagets w/o encountering automatic formatting. As long as that is the case, enjoy!! Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Sunday, February 28, 2010 8:11 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns". According to these rules I would format the following example: --------------- 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. --------------- as: --------------- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. --------------- Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me. Cheers, Adrian
Hi Bill, Don't worry. Nobody wants to force you to use his conventions :) The question really only concerns the code of PharoCore. I think a consistent way of code formatting really is a good idea, even if not everybody agrees with each rule. Cheers, Adrian On Feb 28, 2010, at 18:43 , Schwab,Wilhelm K wrote:
Adrian,
Horrible is an understatement :) Your version is a big improvement. I frequently put ending brackets on their own line with indentation to aid in matching, but not always.
I do not (much) care what conventions the benevolent dictators select for Pharo, but I **do** care that it not be forced on my code that I retain for my own use. There should be ways to compile, export and load code and packagets w/o encountering automatic formatting. As long as that is the case, enjoy!!
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Sunday, February 28, 2010 8:11 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo
I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns".
According to these rules I would format the following example:
--------------- 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. ---------------
as:
--------------- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. ---------------
Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me.
Cheers, Adrian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian, I appreciate the reassurance, and agree that conventions are a good idea. I further agree with Lukas that a formatter is a good way to get there, but want to make the case for doing that in a way that does not force the hands of end-user (which I appear to have done). Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Sunday, February 28, 2010 2:52 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo Hi Bill, Don't worry. Nobody wants to force you to use his conventions :) The question really only concerns the code of PharoCore. I think a consistent way of code formatting really is a good idea, even if not everybody agrees with each rule. Cheers, Adrian On Feb 28, 2010, at 18:43 , Schwab,Wilhelm K wrote:
Adrian,
Horrible is an understatement :) Your version is a big improvement. I frequently put ending brackets on their own line with indentation to aid in matching, but not always.
I do not (much) care what conventions the benevolent dictators select for Pharo, but I **do** care that it not be forced on my code that I retain for my own use. There should be ways to compile, export and load code and packagets w/o encountering automatic formatting. As long as that is the case, enjoy!!
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Sunday, February 28, 2010 8:11 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo
I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns".
According to these rules I would format the following example:
--------------- 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. ---------------
as:
--------------- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. ---------------
Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me.
Cheers, Adrian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
you know go (the language) includes in the language the formatting so there is no discussion. Now I really like to see smalltalk code and not C code because..... It slows me down a lot when I read and I read a lot of code. :) Stef On Feb 28, 2010, at 8:51 PM, Adrian Lienhard wrote:
Hi Bill,
Don't worry. Nobody wants to force you to use his conventions :)
The question really only concerns the code of PharoCore. I think a consistent way of code formatting really is a good idea, even if not everybody agrees with each rule.
Cheers, Adrian
On Feb 28, 2010, at 18:43 , Schwab,Wilhelm K wrote:
Adrian,
Horrible is an understatement :) Your version is a big improvement. I frequently put ending brackets on their own line with indentation to aid in matching, but not always.
I do not (much) care what conventions the benevolent dictators select for Pharo, but I **do** care that it not be forced on my code that I retain for my own use. There should be ways to compile, export and load code and packagets w/o encountering automatic formatting. As long as that is the case, enjoy!!
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Sunday, February 28, 2010 8:11 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo
I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns".
According to these rules I would format the following example:
--------------- 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. ---------------
as:
--------------- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. ---------------
Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me.
Cheers, Adrian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, I have never liked forced formatting; good scanners and parsers have allowed us to move beyond that. Again, I have no real concern over how you chose to format the code in the base system; I would care greatly about any attempt to build that into the language (since you bring it up) or the tools as a mandatory feature. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, February 28, 2010 4:17 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo you know go (the language) includes in the language the formatting so there is no discussion. Now I really like to see smalltalk code and not C code because..... It slows me down a lot when I read and I read a lot of code. :) Stef On Feb 28, 2010, at 8:51 PM, Adrian Lienhard wrote:
Hi Bill,
Don't worry. Nobody wants to force you to use his conventions :)
The question really only concerns the code of PharoCore. I think a consistent way of code formatting really is a good idea, even if not everybody agrees with each rule.
Cheers, Adrian
On Feb 28, 2010, at 18:43 , Schwab,Wilhelm K wrote:
Adrian,
Horrible is an understatement :) Your version is a big improvement. I frequently put ending brackets on their own line with indentation to aid in matching, but not always.
I do not (much) care what conventions the benevolent dictators select for Pharo, but I **do** care that it not be forced on my code that I retain for my own use. There should be ways to compile, export and load code and packagets w/o encountering automatic formatting. As long as that is the case, enjoy!!
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Sunday, February 28, 2010 8:11 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo
I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns".
According to these rules I would format the following example:
--------------- 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. ---------------
as:
--------------- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. ---------------
Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me.
Cheers, Adrian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
thanks adrian On Feb 28, 2010, at 2:11 PM, Adrian Lienhard wrote:
I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns".
According to these rules I would format the following example:
--------------- 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. ---------------
as:
--------------- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. ---------------
Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me.
:) why not like that?
1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ].
On Feb 28, 2010, at 22:12 , Stéphane Ducasse wrote:
--------------- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. ---------------
Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me.
:)
why not like that?
1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ].
The difference is not big, but I prefer the first version because you get one indentation less (and you don't break the rule that an indentation always has only one tab, which is not the case above). Also it makes formatting of conditionals consistent with the formatting of other messages, e.g., receiver foo: x instead of receiver foo: x The rule for ifTrue:ifFalse: follows the same rule, i.e., that keyword messages with more than one argument are put on separate lines: receiver foo: x bar: y Adrian
The configurable formatter can be told from how many keyword messages on it should put them on multiple lines. Also you can give exceptions of messages that you always/never want to put on multiple lines. Lukas On 28 February 2010 22:29, Adrian Lienhard <adi@netstyle.ch> wrote:
On Feb 28, 2010, at 22:12 , Stéphane Ducasse wrote:
--------------- 1    to: (mine size min: his size)    do: [ :index |        (mine at: index) = (his at: index) ifTrue: [            self                instVarAt: index                put: (anotherObject instVarAt: index) ] ]. ---------------
Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me.
:)
why not like that?
1    to: (mine size min: his size)    do: [ :index |        (mine at: index) = (his at: index)            ifTrue: [ self                    instVarAt: index                    put: (anotherObject instVarAt: index) ] ].
The difference is not big, but I prefer the first version because you get one indentation less (and you don't break the rule that an indentation always has only one tab, which is not the case above).
Also it makes formatting of conditionals consistent with the formatting of other messages, e.g.,
receiver foo: x
instead of
receiver     foo: x
The rule for ifTrue:ifFalse: follows the same rule, i.e., that keyword messages with more than one argument are put on separate lines:
receiver     foo: x     bar: y
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Cool. If we can tweak the formatter to fit our needs, I think this is an interesting idea because we would then have really consistent formatting. How does one use this formatter? Something else to consider is that we would need to run the formatter in PharoCore, but it does not contain RB. We could write a small web service that takes some method source as input and returns the formatted code ;) Adrian On Feb 28, 2010, at 22:31 , Lukas Renggli wrote:
The configurable formatter can be told from how many keyword messages on it should put them on multiple lines. Also you can give exceptions of messages that you always/never want to put on multiple lines.
Lukas
On 28 February 2010 22:29, Adrian Lienhard <adi@netstyle.ch> wrote:
On Feb 28, 2010, at 22:12 , Stéphane Ducasse wrote:
--------------- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. ---------------
Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me.
:)
why not like that?
1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ].
The difference is not big, but I prefer the first version because you get one indentation less (and you don't break the rule that an indentation always has only one tab, which is not the case above).
Also it makes formatting of conditionals consistent with the formatting of other messages, e.g.,
receiver foo: x
instead of
receiver foo: x
The rule for ifTrue:ifFalse: follows the same rule, i.e., that keyword messages with more than one argument are put on separate lines:
receiver foo: x bar: y
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian, Another approach would be to have a Seaside app that accepts uploads of .mcz files, loads, formats, and re-saves them into an in-box. I still recommend getting the RB's house in order with respect to comments, but it would work as well as RB users have come to expect. It would also make it part of the release process for a package vs. putting it in the image and affecting "the little guy." Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Monday, March 01, 2010 6:53 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo Cool. If we can tweak the formatter to fit our needs, I think this is an interesting idea because we would then have really consistent formatting. How does one use this formatter? Something else to consider is that we would need to run the formatter in PharoCore, but it does not contain RB. We could write a small web service that takes some method source as input and returns the formatted code ;) Adrian On Feb 28, 2010, at 22:31 , Lukas Renggli wrote:
The configurable formatter can be told from how many keyword messages on it should put them on multiple lines. Also you can give exceptions of messages that you always/never want to put on multiple lines.
Lukas
On 28 February 2010 22:29, Adrian Lienhard <adi@netstyle.ch> wrote:
On Feb 28, 2010, at 22:12 , Stéphane Ducasse wrote:
--------------- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. ---------------
Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me.
:)
why not like that?
1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ].
The difference is not big, but I prefer the first version because you get one indentation less (and you don't break the rule that an indentation always has only one tab, which is not the case above).
Also it makes formatting of conditionals consistent with the formatting of other messages, e.g.,
receiver foo: x
instead of
receiver foo: x
The rule for ifTrue:ifFalse: follows the same rule, i.e., that keyword messages with more than one argument are put on separate lines:
receiver foo: x bar: y
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Another approach would be to have a Seaside app that accepts uploads of .mcz files, loads, formats, and re-saves them into an in-box. Â I still recommend getting the RB's house in order with respect to comments, but it would work as well as RB users have come to expect. Â It would also make it part of the release process for a package vs. putting it in the image and affecting "the little guy."
Instead of complaining all the time about the handling of comments in RB you could provide some tests that demonstrate why you think it is broken. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I'm not complaining; it's simply a fact, and I'm not the only one observing it. Links were given here some time back. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Monday, March 01, 2010 7:28 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo
Another approach would be to have a Seaside app that accepts uploads of .mcz files, loads, formats, and re-saves them into an in-box. Â I still recommend getting the RB's house in order with respect to comments, but it would work as well as RB users have come to expect. Â It would also make it part of the release process for a package vs. putting it in the image and affecting "the little guy."
Instead of complaining all the time about the handling of comments in RB you could provide some tests that demonstrate why you think it is broken. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
send some evidence based on tests so that lukas can give a try to improve the situation. This is what lukas is saying. [Stef] On Mar 1, 2010, at 1:36 PM, Schwab,Wilhelm K wrote:
I'm not complaining; it's simply a fact, and I'm not the only one observing it. Links were given here some time back.
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Monday, March 01, 2010 7:28 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo
Another approach would be to have a Seaside app that accepts uploads of .mcz files, loads, formats, and re-saves them into an in-box. I still recommend getting the RB's house in order with respect to comments, but it would work as well as RB users have come to expect. It would also make it part of the release process for a package vs. putting it in the image and affecting "the little guy."
Instead of complaining all the time about the handling of comments in RB you could provide some tests that demonstrate why you think it is broken.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I'm not complaining; it's simply a fact, and I'm not the only one observing it. Â Links were given here some time back.
Sorry, but this is only a fact if you provide unit tests (or at least a couple of examples) that fail in the latest code base. Otherwise simply nobody cares. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas, File in the attached and then reformat it. I have to admit there has been improvement; at least the comments remain within the cascade of which they were originally a part. Still, they end up out of order with respect to the reformatted code, which is devastating to what I am trying to accomplish. These are directly analogous to the types of comments that sat (in longer cascades) for several years only to save my back side last year. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli@gmail.com] Sent: Monday, March 01, 2010 7:47 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo
I'm not complaining; it's simply a fact, and I'm not the only one observing it. Links were given here some time back.
Sorry, but this is only a fact if you provide unit tests (or at least a couple of examples) that fail in the latest code base. Otherwise simply nobody cares. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Excellent, thanks for the test case. I will have a look as soon as I get home. Lukas On Monday, March 1, 2010, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Lukas,
File in the attached and then reformat it. Â I have to admit there has been improvement; at least the comments remain within the cascade of which they were originally a part. Â Still, they end up out of order with respect to the reformatted code, which is devastating to what I am trying to accomplish. Â These are directly analogous to the types of comments that sat (in longer cascades) for several years only to save my back side last year.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli@gmail.com] Sent: Monday, March 01, 2010 7:47 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo
I'm not complaining; it's simply a fact, and I'm not the only one observing it. Â Links were given here some time back.
Sorry, but this is only a fact if you provide unit tests (or at least a couple of examples) that fail in the latest code base. Otherwise simply nobody cares.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Lukas, Remember, you asked for it :) This might seem very pedantic, and it is. It is also something that has save my bacon more times than I can count. If the RB can preserve things like this, great, I'll use it more. If not, that's ok too, but I can't have it forced on me. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Monday, March 01, 2010 1:32 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo Excellent, thanks for the test case. I will have a look as soon as I get home. Lukas On Monday, March 1, 2010, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Lukas,
File in the attached and then reformat it. Â I have to admit there has been improvement; at least the comments remain within the cascade of which they were originally a part. Â Still, they end up out of order with respect to the reformatted code, which is devastating to what I am trying to accomplish. Â These are directly analogous to the types of comments that sat (in longer cascades) for several years only to save my back side last year.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli@gmail.com] Sent: Monday, March 01, 2010 7:47 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo
I'm not complaining; it's simply a fact, and I'm not the only one observing it. Â Links were given here some time back.
Sorry, but this is only a fact if you provide unit tests (or at least a couple of examples) that fail in the latest code base. Otherwise simply nobody cares.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
You can try with the attached patches. That should put the comments inside the cascade. Since there are no tests for this new behavior (it doesn't break any of the existing ones) I am reluctant of including them right away. It could well be that with these patches in some edge cases comments are lost or suddenly appear twice. Lukas On 1 March 2010 19:32, Lukas Renggli <renggli@gmail.com> wrote:
Excellent, thanks for the test case. I will have a look as soon as I get home.
Lukas
On Monday, March 1, 2010, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Lukas,
File in the attached and then reformat it. Â I have to admit there has been improvement; at least the comments remain within the cascade of which they were originally a part. Â Still, they end up out of order with respect to the reformatted code, which is devastating to what I am trying to accomplish. Â These are directly analogous to the types of comments that sat (in longer cascades) for several years only to save my back side last year.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli@gmail.com] Sent: Monday, March 01, 2010 7:47 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo
I'm not complaining; it's simply a fact, and I'm not the only one observing it. Â Links were given here some time back.
Sorry, but this is only a fact if you provide unit tests (or at least a couple of examples) that fail in the latest code base. Otherwise simply nobody cares.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
-- Lukas Renggli http://www.lukas-renggli.ch
Cool. If we can tweak the formatter to fit our needs, I think this is an interesting idea because we would then have really consistent formatting.
It has dozens of settings that you can configure. It is already integrated with the settings framework in Pharo 1.1.
How does one use this formatter?
aClass compile: (aClass parseTreeFor: aSelector) formattedCode
Something else to consider is that we would need to run the formatter in PharoCore, but it does not contain RB. We could write a small web service that takes some method source as input and returns the formatted code ;)
You only need AST-Core. You can load it in one image, format the code, commit the changes and load the changes into a fresh Pharo image. Also you could unload AST-Core, it has no overrides. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
How does one use this formatter?
aClass compile: (aClass parseTreeFor: aSelector) formattedCode
OB-Refactory also provides a UI to format the whole system or individual classes or packages. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Mar 1, 2010, at 1:23 PM, Lukas Renggli wrote:
Cool. If we can tweak the formatter to fit our needs, I think this is an interesting idea because we would then have really consistent formatting.
It has dozens of settings that you can configure. It is already integrated with the settings framework in Pharo 1.1.
cool!
How does one use this formatter?
aClass compile: (aClass parseTreeFor: aSelector) formattedCode
Something else to consider is that we would need to run the formatter in PharoCore, but it does not contain RB. We could write a small web service that takes some method source as input and returns the formatted code ;)
You only need AST-Core. You can load it in one image, format the code, commit the changes and load the changes into a fresh Pharo image. Also you could unload AST-Core, it has no overrides.
gorgeous :) I feel lucky to have a guy like you around :)
would be nice :) scripting the core from external services Stef On Mar 1, 2010, at 12:52 PM, Adrian Lienhard wrote:
Cool. If we can tweak the formatter to fit our needs, I think this is an interesting idea because we would then have really consistent formatting. How does one use this formatter? Something else to consider is that we would need to run the formatter in PharoCore, but it does not contain RB. We could write a small web service that takes some method source as input and returns the formatted code ;)
Adrian
On Feb 28, 2010, at 22:31 , Lukas Renggli wrote:
The configurable formatter can be told from how many keyword messages on it should put them on multiple lines. Also you can give exceptions of messages that you always/never want to put on multiple lines.
Lukas
On 28 February 2010 22:29, Adrian Lienhard <adi@netstyle.ch> wrote:
On Feb 28, 2010, at 22:12 , Stéphane Ducasse wrote:
--------------- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. ---------------
Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me.
:)
why not like that?
1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ].
The difference is not big, but I prefer the first version because you get one indentation less (and you don't break the rule that an indentation always has only one tab, which is not the case above).
Also it makes formatting of conditionals consistent with the formatting of other messages, e.g.,
receiver foo: x
instead of
receiver foo: x
The rule for ifTrue:ifFalse: follows the same rule, i.e., that keyword messages with more than one argument are put on separate lines:
receiver foo: x bar: y
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
runTest: aSelector
| actualResult expectedResult | [ self logTest: aSelector; clearLog; perform: aSelector ] on: MyTestError do: [ :ex | self log: 'Unhandled Exception'. ex return: nil ].
as you can see, its a bit hard to quickly determine, where ends one block and starts another one. That's why i'm always putting ' ] ' at the next line, and align its indentation to be the same as in opening brace:
[ self logTest: aSelector; clearLog; perform: aSelector ] on: MyTestError do: [ :ex | self log: 'Unhandled Exception'. ex return: nil ].
do you agree that this one is much more readable
Not for me :) May be I read too much Smalltalk code I prefer the rectangle approach of the first one ;)
On Feb 28, 2010, at 1:58 AM, Stéphane Ducasse wrote:
Lukas do you have some code samples. Something that I particularly hate is the following
self bla ifTrue: [ ...
] ifFalse: [ ... ]
I'd like to understand what it is about the above you hate.
That is see in the code.
I want self bla ifTrue: [ ... ] ifFalse: [ ... ]
Does the code in the ifTrue: block begin on the same line? How about the ifFalse: block? If it begins on the same line, then how many indents for the second line? James
On Sun, 28 Feb 2010, James Foster wrote:
On Feb 28, 2010, at 1:58 AM, Stéphane Ducasse wrote:
Lukas do you have some code samples. Something that I particularly hate is the following
self bla ifTrue: [ ...
] ifFalse: [ ... ]
I'd like to understand what it is about the above you hate.
It's like C code, not like a message send. Do you write code like this? aCollection do: [ :each | ... ] separatedBy: [ ... ]
That is see in the code.
I want self bla ifTrue: [ ... ] ifFalse: [ ... ]
Does the code in the ifTrue: block begin on the same line? How about the ifFalse: block? If it begins on the same line, then how many indents for the second line?
IMHO, if the code in the first block is short enought, then it's only a single line, otherwise not, for example: self bla ifTrue: [ self bar ] ifFalse: [ ... ] self bla ifTrue: [ ... ] ifFalse: [ ... ] This book has great guidelines: http://stephane.ducasse.free.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+ 10
I'd like to understand what it is about the above you hate.
It's like C code, not like a message send. Do you write code like this?
aCollection do: [ :each | ... ] separatedBy: [ ... ]
That is see in the code.
I want self bla ifTrue: [ ... ] ifFalse: [ ... ]
Does the code in the ifTrue: block begin on the same line? How about the ifFalse: block? If it begins on the same line, then how many indents for the second line?
IMHO, if the code in the first block is short enought, then it's only a single line, otherwise not, for example:
self bla ifTrue: [ self bar ] ifFalse: [ ... ]
self bla ifTrue: [ ... ] ifFalse: [ ... ]
This book has great guidelines: http://stephane.ducasse.free.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf
Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi James
Lukas do you have some code samples.
Something that I particularly hate is the following
self bla ifTrue: [ ...
] ifFalse: [ ... ]
I'd like to understand what it is about the above you hate.
See levente In addition I have to apy extreme attention to see that the two branches are sent to the same conditional
That is see in the code.
I want self bla ifTrue: [ ... ] ifFalse: [ ... ]
Does the code in the ifTrue: block begin on the same line? How about the ifFalse: block? If it begins on the same line, then how many indents for the second line?
James _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I've commented a version of RBConfigurableFormatter that can format #copyFrom: to the following code. This comes pretty close to the document of Adrian: Object>>copyFrom: anotherObject "Copy to myself all instance variables I have in common with anotherObject. This is dangerous because it ignores an object's control over its own inst vars. " <primitive: 168> | mine his | mine := self class allInstVarNames. his := anotherObject class allInstVarNames. 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ] -- Lukas Renggli http://www.lukas-renggli.ch
Thanks lukas
I've commented
commited :) I guess I saw in on the rss feed :)
a version of RBConfigurableFormatter that can format #copyFrom: to the following code. This comes pretty close to the document of Adrian:
Object>>copyFrom: anotherObject "Copy to myself all instance variables I have in common with anotherObject. This is dangerous because it ignores an object's control over its own inst vars. "
<primitive: 168> | mine his | mine := self class allInstVarNames. his := anotherObject class allInstVarNames. 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ]
can we get rid of the :ind | ;)
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I've commented
commited :) I guess I saw in on the rss feed :)
Yeah.
can we get rid of the
:ind |
Select 'ind', in the context menu select 'refactor source', 'rename temporary'. Then give the new name 'index', press 'ok'. Done. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Feb 28, 2010, at 10:28 PM, Lukas Renggli wrote:
I've commented
commited :) I guess I saw in on the rss feed :)
Yeah.
can we get rid of the
:ind |
Select 'ind', in the context menu select 'refactor source', 'rename temporary'. Then give the new name 'index', press 'ok'. Done.
no i meant self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ] -> self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ] or self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [:ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ] but not starting :ind | at the beginning of the line.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 28 February 2010 22:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Feb 28, 2010, at 10:28 PM, Lukas Renggli wrote:
I've commented
commited :) I guess I saw in on the rss feed :)
Yeah.
can we get rid of the
:ind |
Select 'ind', in the context menu select 'refactor source', 'rename temporary'. Then give the new name 'index', press 'ok'. Done.
no i meant
self class isVariable & anotherObject class isVariable         ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ]
->
self class isVariable & anotherObject class isVariable         ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize)                 do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ]
or
self class isVariable & anotherObject class isVariable         ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [:ind |                         self basicAt: ind put: (anotherObject basicAt: ind) ] ]
but not starting
:ind | at the beginning of the line.
Ahh, that was the mail program that broke it there. Lukas
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Stef, It pains me to have to be a pain about this. I never use a space after a colon; what other people do is their business, but I much prefer having the space gone. Other formatting concerns are far less trivial to me than a personal preference. Lukas is correct about using a formatter, but it has to be a separate or optional step because the current state of formatting is hostile to comments. If moving code to Pharo has taught me anything, it is that I have been correct to embed dated (month-year) comments in my code. The RB scatters them to the four corners, which is why I don't use the thing. I also format code in ways that are analogous to phrasing in music. I tried to capture it in a custom formatter, and quickly realized that I see design, workflow, organizational politics, etc., and the machine sees syntax. It will never "understand" what belongs together and what does not. Anything that forces formatting on me is defective. If there is a way for me to optionally format my code with a Pharo formatter, I'm happy to do so as I turn it over. Anything that I am actively using will be littered with comments (until I tire of them[*]) and formatted in a way that helps me see the big picture long after the machine smashes it down to a mere sequence of byte codes. Bill [*] every so often, I clean out truly obsolete information, but that is more a question of the amount of change that has occurred, not chronological age. In moving to Pharo, I ran across couple of related defects from 2003, and fixed them within an hour thanks to comments in the code. This is one of many such stories that have formed my (somewhat stubborn) thoughts on code formatting. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, February 28, 2010 4:52 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo I would use a formatter, like this you can make it really consistent. The RBConfigurableFormatter is pretty good in that, the only thing I don't like is the placing of the square brackets. I should look into fixing that, otherwise it formats exactly the way I would format myself (and in the way you propose). Lukas On 28 February 2010 10:36, stephane ducasse <stephane.ducasse@free.fr> wrote:
Hi guys
I would like to build a set of canonical code formatting convention for Pharo. I need your help. Now take time before replying :) I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. Once we agree I would like to define a wiki page.
**Space after : rule ============= for example I would like to always have a space after a :
classes := Smalltalk allClasses select:[:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or:[aClass class includesSelector: #cleanUp:] Â Â Â ].
->
classes := Smalltalk allClasses select: [:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] Â Â Â ].
**Block arg rule ============= Do we want a space before and after block arg
Smalltalk allClasses select: [:aClass :method|
-> Smalltalk allClasses select: [ :aClass :method |
** selector or block indented compared to receiver =======================================
Finally do we follow kent block ideas?
classes := Smalltalk allClasses select: [:aClass| Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] Â Â Â ].
-> classes := Smalltalk allClasses             select: [:aClass| (aClass class includesSelector: #cleanUp)                             or: [aClass class includesSelector: #cleanUp:]].
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Adrian Lienhard -
Igor Stasenko -
James Foster -
Levente Uzonyi -
Lukas Renggli -
Schwab,Wilhelm K -
stephane ducasse -
Stéphane Ducasse