El 27/7/2007, a las 23:38, David Chelimsky escribió: > On 7/26/07, Wincent Colaiuta <[EMAIL PROTECTED]> wrote: >> Recently as a result of using Git I've noticed a number of >> inconsistencies in the RSpec codebase with respect to whitespace >> (mixed line endings, mixed use of spaces and tabs for indentation, >> and trailing whitespace at the end of lines). I never would have >> noticed, but Git produces nice colorized diff output which highlights >> these kinds of inconsistencies. >> >> I wanted to ask if the core RSpec team had established any >> conventions/standards for these things. The basic rationale is that >> if all contributors agree to a small number of conventions for >> whitespace there are less likely to be changesets with non- >> substantive whitespace differences (really, false alarms). > > Your thinking makes sense, but we haven't set a standard for this. Do > you know how to configure TextMate (which most of us use) to take care > of this automagically when saving files?
I don't know of any *fully* automatic way to do this in TextMate but there are some things you can do to make it nearly automatic. In my experience I've observed a few things: * The initial "clean up" of a code base is the biggest task (although for a project the size of RSpec we are still only talking a few minutes' work); after that merely maintaining the standards is relatively easy (especially in the case of Git where if you do a "git diff" to see what you are about to commit any problems with the whitespace are immediately evident) * Project-wide Find and Replace does a pretty good job of handling most scenarios; for further "automation" you could record a TextMate macro and assign it to a key combo (for example, to handle trailing whitespace do a regular expression search for " +$" and replace all instances with nothing) * The way the Git community tends to work is to enforce this using repository hooks, and I imagine this could be done in Subversion too: the idea is that you have a pre-commit hook that can check the proposed commit against the standards and reject it if it fails (Git also has a "--no-verify" switch that you can pass if you want to skip the pre-commit hook) * The burden for enforcing the standards need not fall on the maintainers themselves; in the projects I've seen it is normal for a maintainer to say things like, "the patch looks good but can you fix up the whitespace and resubmit?" etc Of course, this is extremely easy and natural when using Git because the diff tools really put any discrepancies "in your face". In any case, I think you don't need to go "all the way" with this; a useful first step would be merely deciding upon some standards and publishing them. Even if you don't take any further steps (enforcement, hooks, automation etc) the mere act of publishing the standards and asking people to follow them would be useful. Cheers, Wincent _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
