On Fri, Aug 22, 2008 at 3:05 PM, Tom Browder <tom.browder_at_gmail.com> wrote:
> On 8/22/08, Kevin Grover <kevin_at_kevingrover.net> wrote:
> >
> > On Fri, Aug 22, 2008 at 3:02 AM, Tom Browder <tom.browder_at_gmail.com>
> wrote:
> >
> > >
> > > I think this has been discussed before, but I would appreciate any
> > > ideas on how to minimize formatting changes from multiple developers
> > > using different operating systems and different editors (and
> > > settings).
> ...
> > I would reformat all code upfront, in one step, and commit it with a
> comment
> > along the lines of "Reformated with 'codeformat ARGS and OPTIONS'". If
> > people reformat as they change things, it becomes impossible to tell what
> > really changed. E.g. the actual code changed get eclipsed by the
> > reformatting changes.
>
> Good idea
> .
> > For day-to-day development, you can either _encourage_ developers to use
> the
> > correct style in the future: this will be mostly automatic if your tools
> > (editor) format the way you want.
>
> That's been the problem--no control over editor settings, and folks
> who have auto wrapping line editors that don't care about line
> lengths. Yuch!
>
> > And/or, you can add a pre-commit hook script that looks at each file in a
> > commit: for each type to which your coding standards apply (i.e. source
> ...
> > the same, the script dies with an error string "Source file XXXX is not
> in
> > the correct coding style:" (you could also append the diff text from the
> > compare). If you have a tool that just checks for coding style, you can
> > also use that and die if it complains.
> ...
>
> > The second approach can be a little draconian.
>
> Yeah, but I bet it gets the attention of those with rogue editors.
>
>
I forgot to mention what I usually do. I have a check target in my Makefile
(or build.xml, or whatever) that runs unit tests and also checks source
code. Mostly this runs my Python code through pep8.py, but I could also use
it for C and other code to check style. My older C code was maintained in a
more manual process - if I ever update it, I start to add these checks.
Then, you just need to beat it into your developers heads to not check in
code (to the main trunk at least) that does not cleanly pass the tests and
format checks.
Socially, for people that repeatedly err, put a Dunce Cap over their door or
on their desk (or some other visible marker to point out who is screwing
up). I've heard of groups doing this for changes that break a build - the
CI (Continuous Integration) environment sends out an email so everyone
immediately knows who screwed up, then they are keepers of the dunce cap
until the next person to err.
I'm sort of surprised that there is not some universal code checking tool
out there. It would be a neat idea to have a generic tool that took BNF
grammers, generic and specific code rules, and checked the code. This type
of tool could easily be extended to reformat code and to markup and output
code for inclusing in documentation. It would also be nice to have one,
consistent, tool that worked with everyhing: Ada, C, C++, C#, Java, Perl,
Python, ....
- Kevin
Received on 2008-08-24 01:09:14 CEST