What are some commonly used source code check-in policies?

Question

I'm curious what code review policies other development shops apply to their source code when it's checked into the source control repository. I'm setting up a TFS (Team Foundation) server, and I'd like to apply some check-in policies to start to stamp out bad practices.

For example, I was thinking of starting with the following couple, so this is the kind of stuff I'm looking for:

• Prohibit empty "Catch" blocks. This would prevent applications from swallowing any exceptions without at least requiring a comment explaining why it's not necessary to do anything with the exception.
• Prohibit "Catch ex as Exception" generic exception handling. Instead, require code to catch specific types of exceptions and deal with them appropriately, instead of just building catch-all handling.
• Require a check-in comment. This one should be self-explanatory, though it seems that TFS (and most other source-control systems) don't require a comment by default.

While these are just examples, they're where I'm thinking of starting, and while I'd like some additional examples of what's popular, I'm open to feedback on these.

Also, though we're a mostly .NET shop, I imagine the popular policies are universal across languages and IDEs (we have some Java development and a few people who will use the repository develop with Eclipse).

Answer 1

Are you talking about check-in policies or code policies?

For check-in policies, I can only think of one that you definitely need:

• The code should compile.

You can add more if you like, but they are not as important.

Answer 2

I wouldn't go overboard with checkin policies. I'd stick to simple checks like, must enter a commit comment, and checking for file name CaSE sensitivity conflicts, etc. I would steer clear of automating code policy screening as others have suggested.