Hi! On mar, 2009-12-08 at 13:12 +0100, Philip Van Hoof wrote: > On Tue, 2009-12-08 at 09:50 +0000, Martyn Russell wrote: > > Hi all, > > > > I have been meaning to write this mail for a while. We have a lot of > > white space inconsistencies in the code and a some trailing white spaces > > too (I am a big culprit on this). > > > > I want to clean it all up and make sure we all use the same policy for > > white spacing in code. > > > > First we need to decide on tabs vs spaces and where. I think last time > > this was discussed on IRC, people agreed to have spaces for function > > alignments and tabs for indentation. Do people still agree with this? > > Note that this means that ALL whitespace involved in the alignment > should be spaces. Not just the last few ones. > > Not this: > <snip>
> It also means ALL whitespace (I repeat but, this is another example): > <snip> I still find that indenting quite cumbersome, emacs has automatic indent-on-tab support and doing anything custom is extra-painful, since there are some circumstances where emacs thinks it's ok to reindent some line (pressing ';' at the end of the line for example), I generally like the glib/gtk+ approach (no tabs), since alignment will obviously be correct, and it's easy for current editors to do that. > > > > I would like to try to make sure this is the case in the code and at the > > I would strongly recommend against going over all lines of code and > starting to change whitespace everywhere. > > Instead work on the module that you're changing for a feature. For > example: > > 1) Before you start with your feature, do a whitespace clean. Commit. > 2) Implement the feature, with right whitespace use. Commit. > 3) Push to git > > I don't think it's helpful if somebody makes huge massive commits that > change the whitespace in all files in one big commit. It'll actually > make development, history, etc quite a horror. > > Please discuss this first on #tracker with Jürg, Carlos, me, Ivan and > Ottela. > > > > same time remove any trailing white space. Choosing the right time for > > this is important too because we have some branches which are likely to > > have merge conflicts. > > > Currently active non-merged branches: > > > > mmc > > miner-web > > msword > > nautilus-extension > > nmo > > quad > > subqueries > > > > When makes sense to make these changes? > > Gradually makes sense. The sudden big commit doesn't make sense to me. Yeah, gradually or "fix as we see" sounds fine to me > > > _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
