about code formatting in pharo

> Stef,
>
> I really like formatters, but as the discussion has already shown, there
> isn't one format that fits everyone's definition of beauty/readability.
>
> Personally I am willing to use any formatter that saves me from having to
> hand edit code for format, but I think I am in the minority.
>
> Presumably the formatter can be configured to produce different output
> formats ... if the format operation avoided dirtying the method, then
> supporting multiple formats would be less onerous ... I can reformat a
> method in my image using my formatter so that I can read someone else's
> code is pretty useful...Along the same line, having Monticello use the
> canonical formatter to format code when writing out mcz files would
> eliminate format issues for saved mczs (note that for source code
> comparison in Monticello, the canonical formatter should be used on both
> strings), finally it might make sense to format code on read, so that
> noone will ever have to know that their chosen format is not the canonical
> one:) ...
>
> Just some thoughts that might minimize the impact of "format wars"...
>
> Dale
> ----- "stephane ducasse" <[hidden email]> 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
> | [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 

> Stef,
>
> To that reasoned response I will add that I do not at all care what others
> choose to use in their code; I simply don't want a formatter applied to my
> code that lives in my image.  Whatever works for you and others in the
> core is fine by me.
>
> Bill
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Dale
> Henrichs
> Sent: Monday, March 01, 2010 1:07 PM
> To: [hidden email]
> Cc: Pharo-project Development
> Subject: Re: [Pharo-project] about code formatting in pharo
>
> Stef,
>
> I really like formatters, but as the discussion has already shown, there
> isn't one format that fits everyone's definition of beauty/readability.
>
> Personally I am willing to use any formatter that saves me from having to
> hand edit code for format, but I think I am in the minority.
>
> Presumably the formatter can be configured to produce different output
> formats ... if the format operation avoided dirtying the method, then
> supporting multiple formats would be less onerous ... I can reformat a
> method in my image using my formatter so that I can read someone else's
> code is pretty useful...Along the same line, having Monticello use the
> canonical formatter to format code when writing out mcz files would
> eliminate format issues for saved mczs (note that for source code
> comparison in Monticello, the canonical formatter should be used on both
> strings), finally it might make sense to format code on read, so that
> noone will ever have to know that their chosen format is not the canonical
> one:) ...
>
> Just some thoughts that might minimize the impact of "format wars"...
>
> Dale
> ----- "stephane ducasse" <[hidden email]> 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
> | [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
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> Stef,
>
> I really like formatters, but as the discussion has already shown, there
> isn't one format that fits everyone's definition of beauty/readability.
>
> Personally I am willing to use any formatter that saves me from having to
> hand edit code for format, but I think I am in the minority.
>
> Presumably the formatter can be configured to produce different output
> formats ... if the format operation avoided dirtying the method, then
> supporting multiple formats would be less onerous ... I can reformat a
> method in my image using my formatter so that I can read someone else's
> code is pretty useful...Along the same line, having Monticello use the
> canonical formatter to format code when writing out mcz files would
> eliminate format issues for saved mczs (note that for source code
> comparison in Monticello, the canonical formatter should be used on both
> strings), finally it might make sense to format code on read, so that
> noone will ever have to know that their chosen format is not the canonical
> one:) ...
>
> Just some thoughts that might minimize the impact of "format wars"...
>
> Dale
> ----- "stephane ducasse" <[hidden email]> 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
> | [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 

> Stef,
>
> To that reasoned response I will add that I do not at all care what others
> choose to use in their code; I simply don't want a formatter applied to my
> code that lives in my image.  Whatever works for you and others in the
> core is fine by me.
>
> Bill
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Dale
> Henrichs
> Sent: Monday, March 01, 2010 1:07 PM
> To: [hidden email]
> Cc: Pharo-project Development
> Subject: Re: [Pharo-project] about code formatting in pharo
>
> Stef,
>
> I really like formatters, but as the discussion has already shown, there
> isn't one format that fits everyone's definition of beauty/readability.
>
> Personally I am willing to use any formatter that saves me from having to
> hand edit code for format, but I think I am in the minority.
>
> Presumably the formatter can be configured to produce different output
> formats ... if the format operation avoided dirtying the method, then
> supporting multiple formats would be less onerous ... I can reformat a
> method in my image using my formatter so that I can read someone else's
> code is pretty useful...Along the same line, having Monticello use the
> canonical formatter to format code when writing out mcz files would
> eliminate format issues for saved mczs (note that for source code
> comparison in Monticello, the canonical formatter should be used on both
> strings), finally it might make sense to format code on read, so that
> noone will ever have to know that their chosen format is not the canonical
> one:) ...
>
> Just some thoughts that might minimize the impact of "format wars"...
>
> Dale
> ----- "stephane ducasse" <[hidden email]> 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
> | [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
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

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

> Gary,
>
> That's pretty much what I just proposed based on your suggestion and a
> "null" formatter.  However it is implemented, the idea is to render the
> code using a formatter so the code itself is not altered.  That will
> hopefully give everyone what they want.  Stef, will that work?
>
> Bill
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Gary
> Chambers
> Sent: Monday, March 01, 2010 1:26 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] about code formatting in pharo
>
> Perhaps a setting to mark saved code "as is" then? Along with an override
> for people who want formatting regardless?
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Schwab,Wilhelm K" <[hidden email]>
> To: <[hidden email]>; <[hidden email]>
> Sent: Monday, March 01, 2010 6:23 PM
> Subject: Re: [Pharo-project] about code formatting in pharo
>
>
>> Stef,
>>
>> To that reasoned response I will add that I do not at all care what
>> others
>> choose to use in their code; I simply don't want a formatter applied to
>> my
>> code that lives in my image.  Whatever works for you and others in the
>> core is fine by me.
>>
>> Bill
>>
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Dale
>> Henrichs
>> Sent: Monday, March 01, 2010 1:07 PM
>> To: [hidden email]
>> Cc: Pharo-project Development
>> Subject: Re: [Pharo-project] about code formatting in pharo
>>
>> Stef,
>>
>> I really like formatters, but as the discussion has already shown, there
>> isn't one format that fits everyone's definition of beauty/readability.
>>
>> Personally I am willing to use any formatter that saves me from having to
>> hand edit code for format, but I think I am in the minority.
>>
>> Presumably the formatter can be configured to produce different output
>> formats ... if the format operation avoided dirtying the method, then
>> supporting multiple formats would be less onerous ... I can reformat a
>> method in my image using my formatter so that I can read someone else's
>> code is pretty useful...Along the same line, having Monticello use the
>> canonical formatter to format code when writing out mcz files would
>> eliminate format issues for saved mczs (note that for source code
>> comparison in Monticello, the canonical formatter should be used on both
>> strings), finally it might make sense to format code on read, so that
>> noone will ever have to know that their chosen format is not the
>> canonical
>> one:) ...
>>
>> Just some thoughts that might minimize the impact of "format wars"...
>>
>> Dale
>> ----- "stephane ducasse" <[hidden email]> 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
>> | [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
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

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

> Gary,
>
> That's pretty much what I just proposed based on your suggestion and a
> "null" formatter.  However it is implemented, the idea is to render the
> code using a formatter so the code itself is not altered.  That will
> hopefully give everyone what they want.  Stef, will that work?
>
> Bill
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Gary
> Chambers
> Sent: Monday, March 01, 2010 1:26 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] about code formatting in pharo
>
> Perhaps a setting to mark saved code "as is" then? Along with an override
> for people who want formatting regardless?
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Schwab,Wilhelm K" <[hidden email]>
> To: <[hidden email]>; <[hidden email]>
> Sent: Monday, March 01, 2010 6:23 PM
> Subject: Re: [Pharo-project] about code formatting in pharo
>
>
>> Stef,
>>
>> To that reasoned response I will add that I do not at all care what
>> others
>> choose to use in their code; I simply don't want a formatter applied to
>> my
>> code that lives in my image.  Whatever works for you and others in the
>> core is fine by me.
>>
>> Bill
>>
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Dale
>> Henrichs
>> Sent: Monday, March 01, 2010 1:07 PM
>> To: [hidden email]
>> Cc: Pharo-project Development
>> Subject: Re: [Pharo-project] about code formatting in pharo
>>
>> Stef,
>>
>> I really like formatters, but as the discussion has already shown, there
>> isn't one format that fits everyone's definition of beauty/readability.
>>
>> Personally I am willing to use any formatter that saves me from having to
>> hand edit code for format, but I think I am in the minority.
>>
>> Presumably the formatter can be configured to produce different output
>> formats ... if the format operation avoided dirtying the method, then
>> supporting multiple formats would be less onerous ... I can reformat a
>> method in my image using my formatter so that I can read someone else's
>> code is pretty useful...Along the same line, having Monticello use the
>> canonical formatter to format code when writing out mcz files would
>> eliminate format issues for saved mczs (note that for source code
>> comparison in Monticello, the canonical formatter should be used on both
>> strings), finally it might make sense to format code on read, so that
>> noone will ever have to know that their chosen format is not the
>> canonical
>> one:) ...
>>
>> Just some thoughts that might minimize the impact of "format wars"...
>>
>> Dale
>> ----- "stephane ducasse" <[hidden email]> 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
>> | [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
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> Stef,
>
> To that reasoned response I will add that I do not at all care what others choose to use in their code; I simply don't want a formatter applied to my code that lives in my image.  Whatever works for you and others in the core is fine by me.
>
> Bill
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Dale Henrichs
> Sent: Monday, March 01, 2010 1:07 PM
> To: [hidden email]
> Cc: Pharo-project Development
> Subject: Re: [Pharo-project] about code formatting in pharo
>
> Stef,
>
> I really like formatters, but as the discussion has already shown, there isn't one format that fits everyone's definition of beauty/readability.
>
> Personally I am willing to use any formatter that saves me from having to hand edit code for format, but I think I am in the minority.
>
> Presumably the formatter can be configured to produce different output formats ... if the format operation avoided dirtying the method, then supporting multiple formats would be less onerous ... I can reformat a method in my image using my formatter so that I can read someone else's code is pretty useful...Along the same line, having Monticello use the canonical formatter to format code when writing out mcz files would eliminate format issues for saved mczs (note that for source code comparison in Monticello, the canonical formatter should be used on both strings), finally it might make sense to format code on read, so that noone will ever have to know that their chosen format is not the canonical one:) ...
>
> Just some thoughts that might minimize the impact of "format wars"...
>
> Dale
> ----- "stephane ducasse" <[hidden email]> 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
> | [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
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project