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" <[email protected]> To: <[email protected]> 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: [email protected] > [mailto:[email protected]] On Behalf Of Gary > Chambers > Sent: Monday, March 01, 2010 1:26 PM > To: [email protected] > 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" <[email protected]> > To: <[email protected]>; <[email protected]> > 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: [email protected] >> [mailto:[email protected]] On Behalf Of Dale >> Henrichs >> Sent: Monday, March 01, 2010 1:07 PM >> To: [email protected] >> 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" <[email protected]> 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 >> | [email protected] >> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
