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
Bug in DXCore 2.2.2 
Sunday, May 27, 2007, 06:38 PM - Code Style Enforcer
Some users of Code Style Enforcer have complained about DXCore 2.2.2 together with Code Style Enforcer. There is actually a bug in the latest DXCore, which makes Code Style Enforcer behave strange and report invalid rule violations, e.g. visibility and interface implementations.

I have reported this to DevExpress and they will have it fixed for their next release. I am now trying to get an answer to when this will be. Until then and if possible use DXCore 2.1.3, which I know will work, or bare with me until the next DXCore version is released.

Read more about the issue here "http://community.devexpress.com/forums/ ... 84403.aspx".
1 comment ( 8 views )   |  related link

The CSEIgnoreRule Attribute 
Wednesday, April 18, 2007, 01:13 PM - Code Style Enforcer
I thought that it could be a good idea to inform you all of the CSEIgnoreRuleAttribute that has been around for some time now. We use it in our project and it is very useful for several reasons.

First of all it clearly documents the reason for violating the code rule, and thus avoids the problem of someone "correcting" it. It also makes the redline disappear from under the rule violation, since the attribute clearly specifies for Code Style Enforcer that it is a deliberate violation.

I will now give you an example of where and when we use it in our project. We demand that all interfaces should be explicitly implemented and for each thus method/property, there should be a matching method/property in the class marked as protected virtual. This makes it possible to override the implementation in derived classes and it also makes it easier and more direct to call local method/properties without the need to first cast yourself to that interface.

But sometimes the protected method/property must be public due to serialization or data binding and when we make it public it violates the explicit interface implementation rule. Therefore it is very nice to be able to clearly specify that we want/need to violate this rule, but it is deliberate, and we can specify why we did so.

In order to use the attribute you must add a reference to the CodeStyleEnforcer.Attributes assembly, which can be found in the normal Visual Studio reference list. Then simply add the CSEIngnoreRule attribute to the member that violates a rule and specify the rule type it is deliberately violating, i.e. Name, Visibility or Implementation. Make sure to also specify a reason for violating the rule.

Another very nice thing with the CSEIgnoreRule attribute is that it only exists in design time in Visual Studio. It never gets compiled into code and thus does not exist in the production code.
1 comment ( 8 views )   |  related link

Some Thoughts about the Next Beta 
Thursday, April 5, 2007, 03:56 PM - Code Style Enforcer
I have received some very nice feedback from developers using the latest beta version of CSE. Therefore the next most prioritized features to be implemented are:

• An easier and more user friendly way to choose between local or global, i.e. shared, rules for a solution.

• Name rules and perhaps also visibility rules must be more flexible, e.g. be able to have different name rules depending on the visibility of a language element. I hope I can make it flexible enough without the need for regular expressions, since I abandoned that path in order to add the auto correction feature.

• Hungarian notation is also something that would be nice to support again, without regular expressions.

If you have any more comments or suggestions, please let me know.

Now you have heard my thoughts about the next version, but of course this can all change, we are living in an agile world after all!
3 comments ( 54 views )   |  related link

Code Style Enforcer Beta Updated 
Sunday, March 11, 2007, 07:00 PM - Code Style Enforcer
I have now updated Code Style Enforcer, after receiving a bug report, that caused problems with selection in the code editor after invoking the context menu for rule violations.

I also added activation/deactivation of Code Style Enforcer to the context menu of the Visual Studio solution.

An uninstall of any previous versions has to be made from the Add/Remove Programs dialog, before installing the new beta version. Why? Well, it has to do with Custom Actions and Upgrade Installations, read my previous blog post for more thorough information.
21 comments ( 100 views )   |  related link

Code Style Enforcer Beta Finally Here 
Sunday, March 4, 2007, 08:27 PM - Code Style Enforcer
Well, it is Sunday evening and I promised a beta version this week and believe it or not, but the beta version 2.1.0 of Code Style Enforcer is finally here.

Please try it out and give me some feedback of both possible bugs or features wished for. Make sure to read the included "readme" file for information about what is new.

Code Style Enforcer now comes with a setup program in order to make life so much easier.

I really hope you like this new improved version...

Known Issues:
The name refactoring to valid names is not always invoked, in fact it is never invoked for local variables, since not supported by the Visual Studio API.

Code rules from previous versions of Code Style Enforcer must be reconfigured using the installed Code Style Enforcer Configurator application, which can be found in the start menu.

Download Code Style Enforcer.


Back Next