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: [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
