Sounds like a good idea. Personally I think it is also a good idea if contributors _avoid_ doing reformats of files, even when the current formatting is "wrong". Try to have as few non-functional changes as possible for easier reviewing and cleaner history. Reformatting of files can be done by a committer directly, in a clean commit with no functional changes. I find that it makes for an easier to understand code history.
/Oskar 2012/5/15 Richard Birkby <[email protected]>: > I think that's a good idea. Perhaps with a batch file to launch vs using > these settings? > > Richard > > On 15 May 2012, at 06:55, cremor <[email protected]> wrote: > > What do you think about providing an exported Visual Studio settings file in > the repository that contains correct C# (and maybe XML and VB) text editor > settings? That way we could just import the settings and be sure that the > coding standards are met (at least those that are controlled by VS > settings). > > On Tuesday, January 3, 2012 1:45:19 AM UTC+1, Julian Maughan wrote: >> >> Tabs should be used. NHibernate mostly follows MS's coding guidelines - as >> enforced by tools like FxCop and ReSharper: >> >> http://msdn.microsoft.com/en-us/library/xzf533w0(v=VS.71).aspx >> >> Unfortunately there are some variations, and although I'm quite active in >> trying to standardize as much as possible its a thankless task. For example, >> I prefer field names to use underscore-camel notation, and generally convert >> existing code to this - particularly if there is inconsistency within a >> class. >> >> On 03/01/2012 12:42 AM, "CSharper" <[email protected]> wrote: >>> >>> Hi, >>> >>> where can I find some information about coding standards in >>> NHibernate? Are they written down somewhere? >>> >>> The easiest thing: should tabs or spaces be used for line indentation? >>> I've browsed some recent changes on the git repository and some pull >>> requests and the diffs there are often much larger than they would >>> have to be because there is a switch between tabs and spaces in the >>> files. That makes reading patches much harder. O.k., an external diff >>> program ignoring whitespace differences helps on the local machine but >>> for browsing the repository online, there's no easy solution.
