Dieser Post wurde aus meiner alten WordPress-Installation importiert. Sollte es Darstellungsprobleme, falsche Links oder fehlende Bilder geben, bitte einfach hier einen Kommentar hinterlassen. Danke.
Developing the same source with more than one person isn't fun: Everybody has his or her own style and with Perl's TMTOWTDI these style may be very different. Perltidy reformats your source to one, common style but this could be very hard when using a versioning system like SVN or GIT.
Problems start when one person forgot to tidy up the code before committing: Then next tidy'ed commit will introduce many "changed" lines where the change is nothing more than perltidy's reformatting of the previous commit. Perltidy easily introduces much more reformatted lines than the really changed lines.
You should start enforcing the tidy rules: Add a simple precommit hook to your SVN server which grabs each committed file, runs perltidy over it and compares the result to the committed file. Finally deny the commit if the two files differ - the committed file wasn't tidy'ed regarding your rules.
Perltidy on Windows defaults to Windows line endings (\r\n) instead of unix line endings (\n), force it to unix style or every single line of each file will "change" during tiding - even if your editor respects the unix format.
If anybody knows a solution, how to tidy each file within a server commit hook, please add a comment. It isn't possible to modify the file-being-committed during the commit - as far as I know.
3 Kommentare. Schreib was dazu-
![]()
anon
29.10.2011 18:11
Antworten
-
![]()
Sebastian
30.10.2011 9:24
Antworten
-
![]()
Gabor Szabo
31.10.2011 8:42
Antworten
Tidying code as a precommit hook? Don't do it. If you're editing existing code then do so using the existing style of the code, even if it's ugly. Maybe "enforce" a shop style for new code. Just don't have precommit hooks that will deny commits based on style, because you're on the fast path to really annoying your developers/contributors if you do.
Sorry, forgot to say that this is a commercial product with full-time-developers. We have a fixed ruleset and tidied all of our source lately.
But I agree, a hook like this won't be good for open source projects. Padre defined "tidy using project rules" as a step on the release-checklist.
I don't think changing code in a pre-commit hook is a good idea even it if is possible.
One solution is to reject the commit if it fails the tidy in the pre-commit hook but that can easily anger people. In open source they would leave and in closed source they work slower, hate you and leave.
Another solution would be to setup a post-commit hook that will run the tidy and commit it as a separate commit as user "perltidy".
A third solution, what we had in padre is to run the tidy in the post-commit hook and then report any issues via e-mail but leave the code as it was.
You might combine 2 and 3 here.