Our team has recently agreed on some very light coding standards, and that we need a means of enforcing them. We already have a mature Continuous Integration practice including frequent, small check-ins and pre-tested commits.
We're considering two methods for implementing an enforcement mechanism: a pre-commit SVN hook, or a dedicated build configuration on the CI server. Here's the trade-offs we've considered so far:
- An SVN hook ...
- (-) requires SVN server admin privileges to setup, which we don't have. We can work with IT, but avoiding the overhead is nice.
- (-) points to a script, which we'd like to keep under version control with the rest of the product. I don't immediately know how to point at the correct hook-script, taking into account branches, tags, and trunk work.
- (-) requires more work for reporting. The script would need to handle both generating and publishing the report.
- (+) gives quick feedback.
- (+/-) provides hard enforcement: the code checks-in, or it doesn't . Usually a good thing (it's called "enforcement" for a reason), but may give false positives.
- The CI build configuration ...
- (-) consumes time on both the CI server and an agent. Might be trivial, but does add up.
- (-) introduces some extra latency, making feedback less immediate.
- (+) easily handles standards that evolve over time, by pointing to the version of the script that exists in whichever branch we're working on.
- (+) provides easier reporting. We already use the CI system for other reports. Adding a new one would be straight-forward.
- (+) configurable enforcement: easier to soften the requirements, if necessary. We could collect a list of violations to fix out-of-band, or provide warnings about standards we're adopting on a trial basis.
What are the trade-offs of these different methods in enforcing coding standards here?
Related: Should coding standards be enforced by the CI server? - Raises some good points, but doesn't consider SVN hooks.