ReSharper 3.1 is out, which you already knew. I put it off until this morning when I read Chris Patterson’s account of the solution-wide analysis and thought about how funny that might be to run against my current project.
I didn’t get too far but I was able to finally reformat (Ctrl+Shift+Alt+F) a class that had thus far been resistant to change, as it were. Oddly, the class went from 9,344 lines of code to 10,255 but damn, does it every look pretty.
Anyway, that’s not what I wanted to talk about today.
While perusing over this shrine to monoliths, I noticed that it had apparently been ported over from .NET 1.1 because all the auto-generated code was still in it. Sensing an opportunity to do good, I decided to create the designer class old-school.
It wasn’t all that difficult to muddle through. You create the class with the same name as the form but named appropriately. E.g. if the form is named Estimate, create a new class called Estimate.Designer.cs and either Visual Studio or ReSharper will wire it up for you. If it doesn’t, you’ll need to modify the project file manually by examining how another form does its nesting.
Once the class is created, mark it and the original form as partial. Then move the components variable, the Dispose method, and the InitializeComponents method into it along with all the form element variables.
But again, that’s not really what I came here to talk about.
It was during this migration from form class to designer class, that I discovered what appears to be an undocumented feature of ReSharper. When I copied InitializeComponents over, I got the expected yellow strip of inadequacy along the right indicating that there were things that could be cleaned up.
Now this being auto-generated code as well as somewhat volatile, I had no intention of cleaning it up. But it occurred to me that I’d never seen this in other designer classes. So popping open another designer class for comparison, the only different was that InitializeComponents was wrapped in a region:
#region Windows Form Designer generated code
So I got to thinkin’, what if I wrapped the entirety of my Estimate form class in a region of this name? And lo! All my inadequacy is gone! No more yellow hints and suggestions on how to make the code better. As far as ReSharper is concerned, my code could not get any better.
I kid, of course. I’m not advocating wrapping your code in cryptically named regions just to avoid seeing the ReSharper suggestions.
But here’s the other thing: You can define your own region text that, when wrapped around a piece of code, will also render its inefficiencies hidden from ReSharper. Here is one way to do it, and I dearly hope there’s an easier way:
- Click ReSharper | Options
- Select "Code Style Sharing" from Languages | Common
- Export your current settings
- Open the exported file in your favorite non-tab-based text editor and scroll to the bottom
- Notice the element, SkipRegions. You should be able to take it from here. You define another child element with the text you want to use (e.g. Ignore this code, Resharper) and remember to increment the length variable (JetBrains doesn’t the childNodes.length property, I guess).
- Go back to "Code Style Sharing" and Import your new xml file
Now you can decorate code with #region Ignore this code, ReSharper and it won’t display any suggestions for improvement. Note that errors will still be marked in red so it isn’t technically ignored completely.
So there you have it. #regions aren’t pure evil after all. Just ornery.
Kyle the Recanted