What about feeding the code to RBConfigurableFormatter before merging so it matches the target style, and then there would be no need to worry about whitespace?
Also I have yet to see someone using spaces for indentation and trailing whitespace (empty lines included) is usually trimmed (but then again people do use different styles so it might not apply). Peter -----Original Message----- From: "Jan Vrany" <[email protected]> Sent: 11/20/2014 2:38 PM To: "[email protected]" <[email protected]> Subject: Re: [Pharo-dev] Source code formatting guidelines Hi guys, thanks for replies. I read books mentioned by Christophe years ago, they're worth reading indeed. But as I said, I'm more interested in 'low level' details like I mentioned: - tabs/spaces? How many spaces if spaces? - encoding of the source string - trailing newlines - trailing spaces - ... The reason is I'm now working with Jan K. on some stuff and he's using Pharo while I don't. To exchange code I read his .mcz when merging his changes and generating .mcz for him when he has to merge my stuff. However, Pharo's merge tool apparently does not do a really great job when it comes to whitespace changes so the merge is difficult and error-prone. The idea is to transform the source just before spitting out the .mcz to minimize these false-diffs when one try to merge. Best, Jan On Wed, 2014-11-19 at 15:19 +0100, Nicolai Hess wrote: > 2014-11-19 14:55 GMT+01:00 Marcus Denker <[email protected]>: > > > On 19 Nov 2014, at 14:47, Peter Uhnák <[email protected]> > > wrote: > > > > how Pharo source code is formatted > > One could argue that this is equivalent to the default > > settings of Pharo formatter. > > Which is not good… e.g. it always adds too many line breaks… > > > Marcus > > > If we can agree on source code guidelines, we should change the > default settings of the Pharo formatter accordingly. >
