Wednesday, September 27, 2006, 07:29 PM - Code Style EnforcerWell, it has taken a little longer than expected to get the next version ready for release.
The good news are that the "fix name rule violation" feature is almost finished. This means that it will be possible to right click on a name rule violation and select rename with a correct name proposal, which in turn will invoke the "rename refactor" function in Visual Studio.
Developer Express has also told me that they will add support for XAML and WPF in a future version of DXCore, which means that we will be able to support that also.
Some more testing has to be done before making this new version available to the public, but stayed tuned...
Thursday, August 24, 2006, 05:34 PM - Code Style EnforcerI can inform you that the team behind Code Style Enforcer has recently doubled up, which means that it now consists of two developers instead of one.
I have also received some feedback from people that have used the plug-in for a while and we are now working on some major changes. First of all we have been making some pretty large refactorings in order to make the code easier to test and maintain, since that is beginning to feel quite important now when more people start using it.
We are also remaking the way name rules are configured. Instead of specifying name rules in form of regular expressions, they will be specified using prefix, case style, i.e. Camel Case or Pascal Case, together with invalid characters. This leads to a new big feature, namely the possibility to automatically correct an invalid name to a valid name. We will probably also make something similar for visibility rules, so that when there is a visibility rule violation, it will be possible to automatically change the visibility to something that is allowed.
There will most likely be more rules added in future versions, like a rule specifying if "this" is to be allowed before members or not. We also have to make some major changes due to .NET 3.0, e.g. event handlers hocked up in XAML are not recognized as event handlers right now, neither are event handlers hooked up through DependencyProperty.Register. My guess is that we have to make some changes to support code rules for both WPF and WCF. How fast and how far we can come with this also depends on the team behind DXCore, since we rely on that for many things.
Stay tuned, the next version with some of the above features is not far away…
Wednesday, August 23, 2006, 06:30 PM - GeneralI am currently away attending the WCF Master Class with Juval Löwy, from IDesign, who actually is the man behind the C# Coding Standard that we base our default code rules on. I can truly recommend this course to anyone who wants to deepen their knowledge in the future of .NET development, which by the way is already here!
Wednesday, August 2, 2006, 01:06 PM - Code Style EnforcerIt always feels good when someone gets their eyes on something that you have developed. It is even more fun when it is the company behind the framework you are using.
Developer Express, the company behind DXCore, has posted an interview about the development of the Code Style Enforcer plug-in.
Read the whole blog post at the community site for Developer Express.
Friday, July 28, 2006, 05:50 PM - Code Style EnforcerNow it is time to finally make my DXCore plug-in available to the public. For those of you who do not know what DXCore is, I suggest you visit Developer Express which is the company behind this incredible extensibility framework for Visual Studio .NET.
So what does this plug-in do? Well, it checks the code against a configurable code standard and best practices. It is developed for C#, but some of the rules will probably also work for VB .NET.
Some of you might ask yourself right now, "Why the heck should I want to use that"? A code standard, huh, what is that about?
So let me tell you about the current project I am working in and perhaps you might want to give it a shot and try it out before you ask yourself these questions.
Far from everyone followed the code standard before, some did, but it was not always The Code Standard, but instead sometimes their own. The reason for not following The Code Standard was not because they did not want to, but simply because they did not see that they actually violated some rules.
Now with this plug-in all code statements that violate a rule in the code standard are underlined with red, and suddenly everyone wants to correct it, since nobody want to commit code that simply does not "look nice".
Some were a little skeptical about it at first, but now after trying it for a few months, my impression is that everyone really likes it and it has become a "standard tool" in our development tool portfolio.
For more information about this plug-in, visit the project page "Code Style Enforcer". Here you will find all releases, installation instructions and some other might-be-good-to-know-about information.
Please try it out and do not hesitate to give me feedback, be it good or bad.
Code Style Enforcer Screenshot