about code formatting in pharo

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

>> ---------------
>> 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
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Adrian Lienhard
>> Sent: Sunday, February 28, 2010 8:11 AM
>> To: [hidden email]
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Lukas Renggli
> Sent: Monday, March 01, 2010 7:28 AM
> To: [hidden email]
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project