[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Automatic formatting of source code

From: Mike Mason <mgm_at_thoughtworks.net>
Date: 2004-01-15 12:08:58 CET

Garrick Olson wrote:

>
>There seem to be a few issues with this approach:
>
>- The end user must initiate this client side task
>
>
But they're going to do that anyhow, right? Otherwise the code they
submit is wrong -- changing their code as it gets submitted is probably
not the best way to educate your users about how to format their code.

>- The client side task must obtain formatting information (style) from
>the
> server (either through svn or shared network resource) and could be
>outdated
>
>
I think commit hooks have access to the file(s) being committed -- can
anyone confirm that? That's certainly the way CVS works.

>- The pre-commit trigger to verify the client did the right thing ends
>up
> duplicating all the work the client just did (potential performance
>issue)
>
>
Yes, but you're trying to fix developer education problems with
technology, so it's going to cost you.

>Another approach I have considered is to do reformatting as a
>post-commit
>action which might initiate and commit a new transaction with formatting
>
>fixes. This approach still has some drawbacks, though. I wonder if
>anyone
>has tried this.
>
>

What I've done previously, with CVS, was to have a single "commit.bat"
script which did a full build and test cycle before committing code.
That process included doing basic things like checking the code for
System.outs, and reminding the user if they had Java files on their
machine that were not added to source control. You could add code-style
checking to a process like that.

Automated changes *after* the user has committed, by some daemon process
that looks at code and reformats it, will probably cause you problems,
not least because a user will probably get merge conflicts the next time
they commit. You'll also clutter file history with formatting changes.

Often, developer education is the best way to proceed, helped by
automated tools that a developer can choose to use -- if you provide an
easy way for them to check their code style, and they believe that
following the coding style is important, they'll do it.

Cheers,
Mike.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 15 12:09:27 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.