Source code inspection framework wanted

June 11, 2007

Another example of problem similar to hashCode() mutability is an option for broken «consistent with equals» contract imposed by implementation of java.util.TreeSet while implementing java.util.Comparator.

Actually, both of these cases (as well as a numerous others) are just an evidence of much wider problem – the requirement to follow some kind of contract various infrastructure implementations rely on and lack of ability to validate/impose such a constraints using existing IDEs and tools. The basic of this is the fact no IDE vendor can track an implementations of an infrastructure libraries existing (the best support feasible to achieve is Microsoft-style solution: an inspection for .Net framework libraries embedded into Visual Studio) and thus creating inspections “by reaction” will always loose the battle.

The best way to avoid the gap between software component and the inspections is to eliminate the “broken phone” between the software developer, the documentation developer and the inspections developer. This presents an «inspection by creator» paradigm – inspections are developed in parallel with a software component (and in ideal case by the the same software developer), embedded within the component, and shipped with it.

Summarizing the basic requirements for such a framework:

  • Development simplicity: the inspection language should provide a way to create an inspections in declarative manner, rather than by reflection-style coding.
  • Lexical compliance: the inspections declaration language should be close enough to the syntax of programming language constructs inspections apply to (thus, there should coexist inspections framework implementations of the common functionality for the different platforms like Java and .Net and different per programming language extensions on the same platform like C# and VB.Net).
  • Multiple inspection sources: there should be and option for predefined inspections (shipped with the framework), vendor inspections (developed and shipped with particular software component) and ad-hoc custom inspections (in-house development of software component users).
  • Binding: there should be a way to associate the inspections with the related code structures (classes, methods, fields and properties) and ideally — keep and maintain them within the code.
  • Universality: inspections should be applied in «to subject» and «to object» manners (i.e. relate to the code structure associated with the inspection or to the code caller).

Upon meeting the two first requirements the last three can be easily accomplished by using existing standard mechanisms like annotations and attributes.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: