Warning: strpos(): needle is not a string or an integer in /customers/a/f/c/fjorden.se/httpd.www/joel/index.php on line 31 Warning: strpos(): needle is not a string or an integer in /customers/a/f/c/fjorden.se/httpd.www/joel/index.php on line 37 Blog by Joel Fjordén a.k.a. Will o Wisp
What New Features to Expect 
Tuesday, January 16, 2007, 07:21 AM - Code Style Enforcer
I have been waiting for Developer Express to release their next version of DXCore and now that they have I will make the necessary updates before finally releasing the next version of Code Style Enforcer.

I thought at least that I could tell you what to expect from the new version, both when it comes to features and bug fixes.

• Code Style Enforcer now comes with an installer to make life so much easier.

• The different rules are now stored as XML files locally to each Visual Studio solution and are added as solution items, in a solution folder that is hidden by default. It is possible to have different rules for different solutions, but it is also possible to share rules between solutions, by linking in the XML files from a common folder. This makes it a lot easier for rules to be source controlled and shared. A windows forms application is also installed, which lets you configure the global default rules that are later copied to new solutions.

• Name rules are no longer configured through regular expressions, but instead with prefix, casing and valid characters. Hungarian notation is not there yet, but will make it into another version.

• Name violations can automatically be refactored to valid names, through a context menu.

• Visibility violations can automatically be refactored to valid visibilities, through a context menu.

• Possible to override violations, by adding an attribute "CSEIgnoreRule" to targets. Why is this a good idea? Well sometimes you simply must have a class called "UTF8", for example, even though numbers are not valid. Then it is nice to be able to add this attribute as an override, which tells Code Style Enforcer that it is a deliberate violation. The attribute also takes a string parameter where one must specify a reason for deliberately violating a rule. This makes it very easy for other project member and yourself to see and remember why the code style had to be broken in that particular case. Another scenario is when always demanding explicit interface implementations, which is not always possible when it comes to data binding or serialization. Therefore it is very nice to be able to clearly specify why a rule had to be violated.

Bug Fixes
• Destructors no longer report name violations, due to ~.

• Operator overloaded methods no longer report name violations.

• Explicit implementations of generic interfaces no longer report name violations, corrected in DXCore.

• Visibility is now also checked on classes, structures and interfaces.

So what is left to do before releasing this new version? Well not that much really, some heavy testing, but most importantly we have to make the refactoring to name rules stable and hook it up to the standard refactoring mechanism. So look back soon and hopefully the next version will be available.

2 comments ( 219 views )   |  related link

Patience Is Everything! 
Wednesday, November 22, 2006, 12:12 PM - Code Style Enforcer
When now being back in the cold north, after having attended Tech-Ed Europe in Barcelona, I will hopefully have some more time for Code Style Enforcer. December is a very busy month for me though, since I have just bought a new flat that requires a total makeover.

I am still waiting for the next release of DXCore, since some new features are needed there. After that I will either make a beta release of the plug-in first, or a final release if it feels complete enough.

I have a lot of new ideas for Code Style Enforcer, which probably will not make it into the upcoming release, but hopefully the one after that. I will tell you more about these ideas in an upcoming post.

Attending Tech-Ed Barcelona 
Wednesday, November 1, 2006, 06:43 PM - General
On Saturday I am heading down to Barcelona for some vacation, but mainly for the Tech-Ed Developers Conference. I am really looking forward to attend some mind-blowing sessions, who knows maybe I will see some of you there...

When I get back in about two weeks from now, I hope there will be a new version of DXCore available, so that we can get the last few things in to the upcoming version of Code Style Enforcer.

Status of Code Style Enforcer 
Wednesday, September 27, 2006, 07:29 PM - Code Style Enforcer
Well, 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...
10 comments ( 2352 views )   |  related link

Thoughts about Future Versions of Code Style Enforcer 
Thursday, August 24, 2006, 05:34 PM - Code Style Enforcer
I 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…
5 comments ( 1819 views )   |  related link

Back Next