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" <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
The answer is that the code is formatted when viewing, from, potentially, unformatted code. Should please everyone. Of course, nothing to stop code being stored in a compact format then.... Regards, Gary ----- Original Message ----- From: "Dale Henrichs" <dale.henrichs@gemstone.com> To: <Pharo-project@lists.gforge.inria.fr> Cc: "Pharo-project Development" <Pharo-project@lists.gforge.inria.fr> Sent: Monday, March 01, 2010 6:06 PM 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" <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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Interesting. One chooses a formatter, with a NullFormatter (does nothing to the code) as an option. Works for me. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Monday, March 01, 2010 1:21 PM To: Pharo-project@lists.gforge.inria.fr; dale.henrichs@gemstone.com Subject: Re: [Pharo-project] about code formatting in pharo The answer is that the code is formatted when viewing, from, potentially, unformatted code. Should please everyone. Of course, nothing to stop code being stored in a compact format then.... Regards, Gary ----- Original Message ----- From: "Dale Henrichs" <dale.henrichs@gemstone.com> To: <Pharo-project@lists.gforge.inria.fr> Cc: "Pharo-project Development" <Pharo-project@lists.gforge.inria.fr> Sent: Monday, March 01, 2010 6:06 PM 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" <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
_______________________________________________ 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, 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale Henrichs Sent: Monday, March 01, 2010 1:07 PM To: Pharo-project@lists.gforge.inria.fr 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" <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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr>; <dale.henrichs@gemstone.com> 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale Henrichs Sent: Monday, March 01, 2010 1:07 PM To: Pharo-project@lists.gforge.inria.fr 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" <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
_______________________________________________ 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
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Monday, March 01, 2010 1:26 PM To: Pharo-project@lists.gforge.inria.fr 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" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr>; <dale.henrichs@gemstone.com> 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale Henrichs Sent: Monday, March 01, 2010 1:07 PM To: Pharo-project@lists.gforge.inria.fr 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" <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
_______________________________________________ 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
Just the issue of "resaved" code then... I suggest a compact format regardelss with "on view" formatting to the user's liking.... Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, March 01, 2010 6:29 PM Subject: Re: [Pharo-project] about code formatting in pharo
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Monday, March 01, 2010 1:26 PM To: Pharo-project@lists.gforge.inria.fr 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" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr>; <dale.henrichs@gemstone.com> 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale Henrichs Sent: Monday, March 01, 2010 1:07 PM To: Pharo-project@lists.gforge.inria.fr 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" <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
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Gary, What is a "compact format?" If it reproduces _exactly_ what I typed (e.g. lossless compression) then I suppose there is no reason to object. If it changes what I see, then I would have to ask for cost/benfit information. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Monday, March 01, 2010 1:45 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo Just the issue of "resaved" code then... I suggest a compact format regardelss with "on view" formatting to the user's liking.... Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, March 01, 2010 6:29 PM Subject: Re: [Pharo-project] about code formatting in pharo
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Monday, March 01, 2010 1:26 PM To: Pharo-project@lists.gforge.inria.fr 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" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr>; <dale.henrichs@gemstone.com> 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale Henrichs Sent: Monday, March 01, 2010 1:07 PM To: Pharo-project@lists.gforge.inria.fr 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" <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
_______________________________________________ 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
_______________________________________________ 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
It makes sense. Stef On Mar 1, 2010, at 7:23 PM, Schwab,Wilhelm K wrote:
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale Henrichs Sent: Monday, March 01, 2010 1:07 PM To: Pharo-project@lists.gforge.inria.fr 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" <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
_______________________________________________ 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
participants (4)
-
Dale Henrichs -
Gary Chambers -
Schwab,Wilhelm K -
Stéphane Ducasse