[rspec-users] Coding standards and whitespace

[Wincent Colaiuta]

El 27/7/2007, a las 23:38, David Chelimsky escribió:

> On 7/26/07, Wincent Colaiuta <win at wincent.com> 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