Visual Studio add-in for validating string.Format method

Question

string.Format is a very risky method. There are a lot of thing that could go wrong, without any compilation errors:

string.Format("{0{", text);
string.Format("{1}", text);
string.Format("(0)", text);
string.Format("{0}", text1, text2);

I'm looking for a way to find this problems in compilation time. If I remember correctly, Resharper find some of those errors, but it's too rich for my blood.

Conversationalist

Save up for ReSharper -- worth every penny. – Geostrophic

ReSharper catches all of the above mistakes, not just some. – Teleprinter

So, I'll either buy ReSharper or write this extension myself? No 3rd option? – Conversationalist

Just curious, why do you need such validation? I think the examples you listed are no different for any ordinary developer bugs that should be caught in Peer Review or Unit testing. – Glorify

@J Angwenyi: I'm now doing a major refactoring and replacing the old in-house logger with Common.Logging. It's a lot of repetitive work, and I probably miss a few. There are currently no unit tests for this module. Furthermore, this kind of tool could help in everyday work, especially in those weak, humanly moments that we skip all the regulations and bureaucracy - and just checking stuff in. – Conversationalist

@J Angwenyi - knowing you made a mistake at the instant you make it saves a ton of your time, and the time of everyone involved after the fact. Also, a lot of errors of this type I've seen are in catch blocks, and unless you are really covering your code with your unit tests, then you have a time bomb in the code. – Rufe

@arcain: Exactly. I've encountered so many times says like "I only added some log inserts. It's compiling. What could go wrong?" – Conversationalist

A 'dangerous' problem is one you can't easily detect. That's just never the case with string.Format(). – Caylor

@Hans Passant: It's easy to detect, but only on runtime. One could spend a lot of time on integration testing because of those little mishaps. I can't realize why this subject being disputed. I even got a downvote. – Conversationalist

You could try writing your own custom StyleCop rules to catch things like this. You should be using StyleCop, FxCop or any code analysis for that matter. – Twist

Unit testing as part of rollout? – Jamille

I've seen this kind of thing cause problems in shipping products many times. The format is often used to generate a log or error message in an exceptional circumstance, one that never occurred during testing. – Jobye

@arcain, @Bernard, @antsyawn: progress update is available in my answer below. – Conversationalist

This should be a simple RegEx for covering 90% of the cases. Is there any extension that does this besides ReSharper? I would love an update for 2014. – Lobbyist

Answer 1

Resharper does that for you -- even at edit time :-).

However be aware that things like

String.Format("{0} blabla", foo, bar);

Do not generate an error (after all, deciding to hide a value is perfectly fine).

Audriaaudrie

Answer 2

String format verification for .NET2.0

After some research, I've found out that FxCop already contain a rule for string format checking (Usage Rules\Provide correct arguments to formatting methods). It's even identifies the example in @Sklivvz answer. Unfortunately:

1. The rule exist only in the old 1.35 version but not in 1.36 (see: Discontinued FxCop rules in V1.36).
2. The existing of lambda expressions in the code yield no rule errors or exception message. It just stops the check without informing. I'm guessing that's because V1.35 uses .NET runtime 2.0.
3. The rule only cover calls for Console.Write, Console.WriteLine, string.Format & StringBuilder.AppendFormat. I managed to tweak it (using Reflector) to also cover Common.Logging.ILog.DebugFormat, but I'm pretty sure it's contradicts with MS EULA ("You may not reverse engineer, decompile, or disassemble...").

So, you can safely use FxCop for testing string formatting in your .NET2.0 apps.

---

But what about newer .NET versions?

For all of you working with more up-to-date versions, I've written a StyleCop rule that check string literals for common format error patterns. It's far from perfect and yield many false positives but still cover allot.

I would like to check the new FxCop SDK for a more comprehensive solution.

I will post my conclusions here.

Conversationalist

Thanks a lot, you saved me a ton of time in trying out FxCop to get this to work! I think your link to "Discontinued FxCop rules in V1.36" is broken though. I'd be interested in your StyleCop rule and further conclusions – Flimsy

Answer 3

Resharper will help you identify it But it is very heavy and have to be use with care if you are work on existing application.

Redd