DXCore: more wholesome goodness

It's not generally known but we make DXCore, the base software that both our CodeRush and Refactor! Pro products use, available as a free download. Essentially, DXCore wraps the somewhat-difficult-to-use VSIP interfaces in a neat .NET package with extensibility points, and also provides some extra functionality for Visual Studio available nowhere else. Using DXCore, you too can make some rather nifty tools for Visual Studio that use the same visual effects we use in CodeRush and Refactor! Pro. We provide some documentation for this, but we also have a very active newsgroup for DXCore on our server, and there's even a community site that supports development using DXCore.

Just the other day I learned of a new DXCore plug-in that sounded very intriguing, something that I hadn't thought of, or, if I had, it hadn't really registered. Joel Fjordén has implemented a plug-in for DXCore that checks compliance against coding standards. Now, to me, coding standards are a bit of a bête noire: in my previous job I wrote the coding standards that the development organization were supposed to follow, but that were pretty much ignored. It almost seems that if you put fingers to keyboard in an IDE, you automatically have your own coding standards, so the thought that someone had written a plug-in that checks for adherence to some departmental standard was very interesting.

Anyway, I was interested enough to ask Joel what prompted him to do this and how he'd fared and he was gracious enough to answer. Thanks, Joel!

ctodx: What made you use a DXCore plug-in for your coding standards checker rather than say a console app that batch runs through the source files at check-in?

JF: Well, first I thought about doing a stand-alone application, but then I got the idea of making a Visual Studio add-in instead. I had this idea of having all code style violations end up in the IDE's Error List. I gave up this idea really quickly, since the API for this wasn't that nice and easy to work with. It would simply have taken too much time, without giving me a lot of satisfaction.

After listening to a podcast on .NET Rocks, I heard about CodeRush and Refactor so I just had to try them out. I was really impressed, especially with the visual experience that these two products use. I then read some more about DXCore and came up with the idea of making a more "visual" code style enforcer, so I suppose "visual experience" is really the answer to your question. As it works now, the user gets immediate feedback when writing code: the code statements that violate any rules are highlighted and the programmer is instantly reminded.

ctodx: What kind of coding standards are checked with your plug-in?

JF: There are three types of rules at the moment: name rules, visibility rules, and implementation rules.

The name rules define valid names for fields, constants, readonly fields, variables, parameters, properties, methods, event handlers, classes, structures and interfaces.

The visibility rules define the visibility that is valid for different members. It’s also possible to specify that the visibility has to be specified explicitly.

The implementation rules define that interface implementations have to be made explicitly or implicitly.

ctodx: How does a coding standards violation show itself?

JF: The code block that violates a rule is underlined in red. This is a really nice and simple feature that DXCore offers. The nice thing with this line is that it isn't a normal straight line, but instead a line that looks like it has been drawn by hand, which makes it much more appealing.

There are also tooltips with information about the violation that appear when hovering over an underlined statement.

ctodx: How often does the checking engine run?

JF: As soon as code is entered or a code file is opened. The code standard for a language element is actually checked when the event is fired for a language element to paint itself. This means that only language elements that are currently visible are validated.

ctodx: How easy was it to write?

JF: It depends on what you compare it with. If you compare it to writing the same thing using the VSIP API, I think it was really easy. The hardest part was to know where to start looking for information. The first breakthrough was when I watched an episode of dnrTV with Mark Miller where he wrote a DXCore plug-in in something like an hour.

The documentation was rather thin I think, but the newsgroup for DXCore plug-ins has been an invaluable source of information, since it's actually possible to ask questions there and get answers.

ctodx: How many developers now use your plug-in?

JF: Right now we have about 10 developers in the current project. Not everyone followed the coding standard before; some did, but they still inadvertently violated it from time to time when not thinking about it. Now with this plug-in all code statements that violate any rules in the coding standard are underlined with red. Suddenly everyone wants to correct it, since nobody want to check-in code that simply doesn't "look nice" when someone else looks at it.

I personally think that it's very important to follow a coding standard. It becomes more and more important the more developers there are in a project, since there is more opportunity for coding standards violations to creep in, making the code harder to read.

(Have you built an interesting application with our products? Does it use some unusual feature that we might not have seen elsewhere? Let me know, and I'll write it up here.)

Free DevExpress Products - Get Your Copy Today