Re: Automatic formatting of source code

I put formatting into the build scripts whenever you do a clean compile.

And for someone to check their code in they follow this procedure:
  clean compile (does format)
  update
  clean compile (does format - but usually wont actually format anything)
  commit

As everyone follows procedure ;-) you can always assume that the deltas will
be against correctly formatted code.

The major issue I had was making sure you don't reformat code thats already
formatted. Most formatters around seem to rely on timestamps. I patched
Jalopy - for java code - to use CRCs instead so even if the file is changed
when you run update it wont be formatted in the clean compile before the
commit.

The reason I really wanted to do this was because I like to format the code
I'm working on to suit my style this way i can format it to my style and
format it back to the standard when i commit.

Thats my 2c anything

Michael
On Thu, 15 Jan 2004 14:24, Garrick Olson wrote:
> -- Eric wrote:
> > The best bet (and the solution I settled on) was to have the client do
>
> the
>
> > task, and then let the server check the results and optionally abort
>
> if
>
> > they are not correct. This solves the "client not doing the right
>
> thing"
>
> > problem.
>
> There seem to be a few issues with this approach:
>
> - The end user must initiate this client side task
> - The client side task must obtain formatting information (style) from
> the
> server (either through svn or shared network resource) and could be
> outdated
> - 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)
> - If the client did the wrong thing, this failure must be made visible
> to
> the end user, and that user must then initiate a client side task to
> fix it
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

-- 
Michael McCallum
Software Engineering Manager
SnapHire Inc
http://www.SnapHire.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org