One of the biggest issues facing developers of reusable libraries is backward compatibility. When you get to work on version 2.0 or later, you will inevitably regret some of the choices you made in the previous version. Typical issues include:
- We should have named this method XXX instead.
- This should have been a method, not a property.
- We should have put these types in their own namespace.
- We should have used an enum instead of a bool for that parameter.
Unfortunately, fixing any of these issues could break existing code. Even though you may have very good reasons to change the API, your customers won’t be happy.
I read a suggestion recently to use the Obsolete attribute to aid in the conversion. This class has a Message property that can be used to inform the user of the recommended alternative.
Now, wouldn’t it be nice if, in addition to this message, you could specify the required changes in a formal manner using attributes. With Visual Studio 2005’s refactoring support, it should then be relatively easy to write an add-in that interprets this information and performs the necessary changes for you. This would work only for relatively simple modifications. But it would still be a big help, and make the transition to compliant code a lot easier.
With the creation of the .NET platform, Microsoft has taken the potential for developer productivity to the next level. .NET is much more than a Virtual Machine environment with an extensive class library. It is a platform for efficient programming. Here at Extreme Optimization, we have completely embraced this side of the framework.
Yet, as the comments to a recent blog entry from Brad Adams show, not everyone cares like we do. (He rightly points out that compliance with the Design Guidelines should be a requirement.)
What is surprising is that even some of the big names in component development, like Infragistics and ComponentOne, get bad marks.
Currently, Microsoft’s partnership programs for ISV’s are based solely on what the ISV is prepared to pay for the co-marketing opportunities that come with them. There is no consideration whatsoever for the quality of the products.
I believe it would be in the interest of Microsoft as well as the developer community as a whole to create some kind of “Built for .NET” logo program, with strong quality and guideline compliance requirements. This would encourage good design, and increase the effectiveness of developers across the board, giving the .NET platform a distinct advantage over its competition.
Now, software design is somewhat subjective, and the design guidelines should not be taken as absolutes. Our own libraries violate some of the guidelines, because some general assumptions simply don’t work well for numerical software. However, a core set of design rules should be mandatory (for example: require enums instead of numerical codes), while a certain number of violations of less stringent requirements would be allowed. Alternatives should be provided for violations, and the violations themselves should be marked with the Obsolete attribute. Etc., etc.
Just my 2 cents…