This weekend I posted 5 simple ways to reduce your code using Resharper (tips 1-5). I decided to follow that up with another set of 5 quick and easy tips, so here they go. Hopefully these tips will show you some things I do to turn on (and off) some refactoring suggestions.
Tip 6) Remove Parameter, and Update Usages
I had a method in an interface where at one point I was using 3 parameters. Somewhere along the way I stopped using one of the parameters, and Resharper was kind enough to point this out tome. It can easily remove the parameter and update all usages so all classes that implement the interface are updated. To find the suggestion you can either run the Find Code Issues feature or go to the file and press F12. Then
- ALT + ENTER
Tip 7) Use the ?? Operator Instead of If/Then for Null checks
Anytime you want to grab an object or collection and you may get it from multiple places, you might be creating if/then logic to handle this. You can actually use the ?? operator which shortens the code and is just as readable (more so to me). The ?? operator executes the left most expression and returns it if it is not null. I t continues executing the expressions to the right only if the previous ones were null. So you can take code like this:
- ALT + ENTER
and it becomes this
Tip 8) Ignore Some Suggestions
You may not agree with some of my tips nor Resharper’s tips and that’s totally your call. I tell Resharper to stop suggesting some tips since I don’t want to follow them. For example, I don’t like how it keeps telling me to make classes static or sealed. If I wanted them to be static I would have done so in the first place
I highly recommend you customize Resharper to ignore some of the tips so you spend less time being alerted to things you don’t care about.
Here is how you can tell Resharper to ignore such a situation. Here it tells me my class can be sealed. So I click the “Inspection options …” choice.
I am then presented with this dialog and I choose “Do not show” then click OK.
Now it won’t bother me anymore with this suggestion. You can also tell lower or raise the severity of the inspection option, here.
Tip 9) Use var When the type is Obvious
This is sure to be one of the most controversial refactoring options I mention. I like using the var keyword when it is really obvious what the type is. I do this in several cases where it is obvious such as initializing an integer or if the type is on the right hand side of the expression. Resharper helps with this (which you can turn off using the previous tip).
So here we have a Dictionary<string, string> which is repeated on both sides. Seriously, do I need to see that? Not me. So a quick
- ALT + ENTER
I find this much more readable.
So where would I not use var? If its not more readable and not obvious what the type is, such as when you can a method that does not make it obvious what is being returned, then do it.
var foo = GetSomeValue();
Tip 10) Removing Redundant Event Handler Type Declarations
I get blurry eyed seeing all that code that gets created when we generate event handlers. Don’t get me wrong, I absolutely love how we can type += then TAB +TAB and the event handler declaration (and the event handler) are creat ed. Nobody wants to memorize that syntax. But I don’t need to see the extra code. What am I talking about? Here is what is created when I type
- Loaded +=
Very cool that I don’t have to type that. But, I don’t need the “new System.Windows.RoutedEventHandler” to be explicit since the event handler method already defines it to be the correct type. So if I put my cursor on that code (or hit F12) I can type
- ALT + ENTER
and the event handler assignment becomes this
Much cleaner and much more readable, in my opinion.
Of course, all of these tips are my preferences. Use or ignore as you see fit.
You can do these one at a time or you can set all of these rule sup using the “Find Code Issues” feature of Resharper. Before I run any solution wide code changes I like to first understand what I am changing and customize it.