Wednesday, April 08, 2009

CodeRush, when code smells...

At the beginning of this month Devexpress released the new version of their DXPerience products for .NET (Version 2009.1)
With the release of this components they also released a new version of their coding assisting tool CodeRush and Refactor Pro.
We use CodeRush for a couple of years now in Visual Studio for our C# work. Strange enough this new version somehow managed to trigger the "wow" factor once again.
I will not explain every new feature here, (You will find some resources at the end of this post) but one that is awesome in particular is Code Issues.

The Code Issues feature analyses your source code while your are working in your code. It gives you hints for Unused namespace references, unused methods, undisposed local vars etc, etc.

How does it work?
Hints appear in a bar near the scrollbar of the editor when you hover the mouse over the colored lines (each color is a hint category):
Code Smell  
In this particular example, which seems to be extracted from some farmer application ;-), Coderush hints that a line of code where two strings are concatenated, could be refactored using string.format.

When you hover the code line, it shows you what you could do to improve your code: (or make it smell better)cr1
This is really an impressive cool feature, that will boost the quality of your code.

Delphi Prism
Unfortunately CodeRush only supports C# and VB.NET at this moment. It would be very nice if CodeRush would support Delphi Prism as well.

Beside the fact that CodeRush helps you to boost your productivity with lots of code templates, it also helps you to track code smells and refactor them out of your software which will eventualy increase the quality of it.

You can find more resources on CodeRush here:
The Devexpress website
Mark Miller blog post "What's new in CodeRush & Refactor Pro"
This blogpost by Rory Becker


gabr said...

Nice feature but still - why should System.Format be better than string concatenation???

Roland said...

Well it is considered better from the readability perpective. (iow maintainability)
It drills down to the coding standard you r using. But this was just a simple example, why would a Cow say anything at all? ;-)

Rory said...

In a slightly larger example...

s = "Cow says " + Cow.Make + "Several times"; better phrased as...

S = String.Format("Cow says {0} Several times",Cow.Make);

..for performance reasons.

There are fewer strings in the 2nd version (2 vs 3). Therefore it's less memory intensive (especially in large loop)

gabr said...

That's something I would believe only if you profile & time both versions.

Mark said...

Strings passed to String.Format are also easier to translate/localize than concatenated strings. For example, the string expression "The cow says " + Cow.Make + "." might need to be reorganized grammatically when translating to another language (e.g., Cow.Make + " is spoken by the cow."). Grammatical changes like this (which are common when localizing your application for other cultures) cannot happen when string concatenation determines the order of the sentence parts (at least not without changing th *code*), however they are easy to do when the string to be translated includes all the grammatical parts of the phrase (e.g., "The cow says {0}."). One additional benefit: having the entire phrase in one string provides more context to the translator, so the translations tend to be of a higher quality.

gabr said...

Now _that_ is an excellent reason. Thanks for pointing it out!

Anonymous said...

I just this was also available for Delphi. I really miss Code Rush for Delphi. Not that I have ever used it but after trying a demo version some time back in VS2005 I personally feel that this Add-in should also be made for Delphi. It will make life of developers easier.

James Curran said...

s = "Cow says " + Cow.Make + "Several times";

would be faster than using String.Format(). The compiler would automatically translate it to
String.ConCat("Cow says ", Cow.Make, "Several times")

The one string vs two is irrelevant, as those those constant strings are built at compile time.

The other reason preferring String.Format are still valid.

Mark said...

Hi James,

> Actually,
> s = "Cow says " + Cow.Make
> + "Several times";

This example shows another characteristic of string concatenation: display bugs can be harder to spot in the code and may instead be caught at runtime, sometimes by customers after you ship.

The potential display bug in the code above isn't so obvious when string concatenation is used.

Consider what happens when Cow.Make returns "Moo". The message displayed becomes: "Cow says MooSeveral times".

But take a look at how that display bug is so much easier to spot in the code when you use String.Format:

string s = String.Format("Cow says {0}Several times", Cow.Make);