Installation instructions and brief guide

The code should build and install without problems using VS2010. It's possible that not all editions will build the project. The code has been developed using VS2010 Premium, running on Window7 Ultimate.

Unless you have licensed the database development edition, the static rule set will be of no use to you.
The binaries are compiled on a 64-bit machine, but should run anywhere.

The project post-build step deploys the binaries and config files to the Neznayka folder under VSTDB\Extensions in the VS2010 installation directory.
The 10 initial static analysis rules, and the 12 subsequent ones in release 2, should display immediately when you navigate to the Static Code Analysis tab for your database project.
If you wish to remove Neznayka, just delete the Neznayka folder under VSTDB\Extensions.

The project makes use of the Nini windows configuration file system.
This dependency may be removed in future releases.

TODO

Short term

  • Make rule numbering and descriptions configurable.
  • Internationalise the rule numbering and descriptions.

Medium term

Enlarge the rule-set. Under active development

Medium-Long term

Migrate to VS2012 and SQL Server 2012, always supposing that Microsoft's plans for those products allows this to happen.

For further information on Neznayka see http://en.wikipedia.org/wiki/Dunno

Current Rule Set


DM0001 – Avoid unused variables. They indicate incomplete code with potential errors.
DM0002 – Avoid uninitialised variables. They indicate incomplete code with potential errors. Variables that are used but never set to a value are possible bugs.
DM0003 – Avoid write-only variables. They indicate incomplete code with potential errors. Variables that are only ever written to serve no purpose.
DM0004 – Avoid unused table variables. They indicate incomplete code with potential errors.
DM0005 – Avoid unused parameters. They indicate incomplete code with potential errors.
DM0006 – Avoid short variable names, apart from numeric variables used for indexing purposes. (Configurable – see dll.config). The config file has one entry to indicate the minimum permissible length for variable names, and one entry with a list of data-types for which the rule is optional. The list consists of a number of TSQL data types, one per line, without spaces.
DM0007 – Avoid numeric suffixes to variable names. They are an error-prone way of making variable names unique.
DM0008 – Avoid variable names that are too similar. They cause confusion.
DM0009 – Avoid short parameter names, apart from numeric parameters. (Configurable – see dll.config). Similar to DM0006, but has a separate rule, because parameters are part of your published interface and consequently may require different rules.
DM0010 – Avoid parameter and variable names that fail to conform to the naming pattern. (Configurable – see dll.config). The naming pattern should be expressed as a .NET 4 Regular Expression. See the .NET online documentation for details. The regular expression must not be split across multiple lines in the config file.

DM0011 – Tables defined in the project should have a primary key also defined in the project.
DM0012 – Tables defined in the project should have a clustered index also defined in the project.
DM0013 – Tables defined in the project with a clustered key should be clustered on a primary or foreign key also defined in the project. (Configurable – see dll.config).
DM0014 – Foreign keys defined in the project should be supported by an index also defined in the project.
DM0015 – Indexes and constraints defined in the project should not have duplicate columns.
DM0016 – Indexes and constraints defined in the project should not be duplicated or subsumed by other indexes and constraints.
DM0017 – Unique indexes defined in the project should not normally contain nullable columns.
DM0018 – Unique constraints defined in the project should not normally contain nullable columns.
DM0019 – Unique constraints or indexes should not be subsumed by more tightly defined indexes or constraints.
DM0020 – Clustering key columns need not normally be repeated in other indexes defined in the project.
DM0021 – Indexes should not have more than a certain number of columns in the key. (Configurable – see dll.config).
DM0022 – Constraints defined in the project on non-temporary objects should be named.


Rules DM0011 - DM0022 only cover objects defined in the current project. Objects imported from other projects are not covered, and code that manipulates them will not be picked up. Similarly, objects defined in code are not covered by these rules. The hidden agenda behind this decision is to encourage you not to create and dispose of objects in code.


Last edited Apr 28, 2013 at 4:01 PM by DedMedVed, version 13