views:

73

answers:

4

AGAIN: If you're voting -1, please leave a comment explaining why. This post isn't about whether or not you approve if this approach, but how to go about it.

Like many architects, I've developed coding standards through years of experience to which I expect my developers to adhere.

This is especially a problem with the crowd that believes that three or four years of experience makes you a senior-level developer.Approaching this as a training and code review issue has generated limited success.

So, I was thinking that it would be great to be able to add custom compile-time errors to the build process to more strictly enforce our in-house best practices and coding standards.

For instance, we use stored procedures for ALL database access, which provides procedure-level security, db encapsulation (table structure is hidden from the app), and other benefits. (Note: I am not interested in starting a debate about this.) Some developers prefer inline SQL or parametrized queries, and that's fine - on their own time and own projects.

I'd like a way to add a compilation check that finds, say, anything that looks like

string sql = "insert into some_table (col1,col2) values (@col1, @col2);"

and generates an error or, in certain circumstances, a warning, with a message like

Inline SQL and parametrized queries are not permitted.

Or, if they use the var keyword

var x = new MyClass();

Variable definitions must be explicitly typed.

Do Visual Studio and MSBuild provide a way to add this functionality? I'm thinking that I could use a regular expression to find unacceptable code and generate the correct error, but I'm not sure what, from a performance standpoint, is the best way to to integrate this into the build process.

We could add a pre- or post-build step to run a custom EXE, but how can I return line- and file-specifc errors? Also, I'd like this to run after compilation of each file, rather than post-link.

Is a regex the best way to perform this type of pattern matching, or should I go crazy and run the code through a C# parser, which would allow node-level validation via the parse tree?

I'd appreciate suggestions and tales of prior experience.

Comments Several respondents have pointed out that it's possible to restrict the ability of a user to run anything but a stored proc through db permissions. However, we're in the process of porting a 350k+ line application from ASP 3.0 to ASP.NET MVC, and the existing code base relies pretty heavily on concatenated SQL, whereas the new stuff all uses Enterprise Library. I guess I could add a separate web user account for the .NET code with more restrictive permissions.

+1  A: 

What about writing a plugin for Resharper? Here is a tutorial to start with: Writing plug-ins for ReSharper: Part 1 of Undefined

Giorgi
+1  A: 

For coding standards I would look at writing custom rules for FxCop or StyleCop. I don't think Regex would be a suitable tool for the job.

For the specific case of requiring Stored Procedures - if you ensure the application doesn't have permission to do anything else on the production database, everyone will soon fall in line.

Joe
+1 for the DB permissions suggestion, but even restricting access to stored procedures only still allows creation of concatenated SQL such as "exec my_stored_proc '"+val1+"','"+val2+"'" which is less than ideal. Also, can I force StyleCop or FxCop to run? I suppose I could do it on the source control server. Hmm.
David Lively
"I suppose I could do it on the source control server" - probably the best way, you probably don't want to incur the performance penalty of code analysis on every build. I think it would be possible to create an FxCop rule that flags attempts to call ADO.NET methods with CommandType set to anything other than CommandType.StoredProcedure.
Joe
+1  A: 

Implicit typing (var x = ....) is a feature that can be turned off on project level in visual studio.

The other one is trickier. Have you had a look at FxCop, which is the tool for enforcing code standards.

Krumelur
A: 

The requirement that only stored procedures can be used should be managed through database permissions. The rule against using var seems fairly arbitrary to me and I can't think of a way to enforce it. Do you have any more examples of your best practices?

Jamie Ide