Using ReSharper to remove Code Smells and Keep Code Cleaner

I promote ReSharper always as a necessary tool that I feel all developers should definitely be using.  In fact there are teams I've been on that require it as they've decided that the tool is so useful that everyone should be on board and using it because it helps so much that it became a requirement to use it literally.  And on those teams developers didn't debate using it, they were already using it or if they weren't they were all for it because they saw how it can literally help the team to be more efficient in so many ways.

One of the big reasons to try and make it a standard on your team is about is keeping code clean.  Some people don't think they have any use for a tool like ReSharper.  They're "proud of manually coding everything without much assistance from intellisense".  Well that's just ignorant.  And most likely those kind of developers are producing code smells for the rest of the team and they don't even know it or causing themself extra pains that they weren't even aware were walls/pains in the first place on a day-to-day basis!

And remember your code is everyone's code.  The code base belongs to the entire team, not just you.  So if you think it's ridiculous to keep even the smallest lines of code clean and it's below you, you might consider another profession.  Do you think accountants allow messes?  Doctors?  The answer is no and it should be no different in our profession as Software Engineers or "Craftsmen".  What you do affects everyone in your development team so you need to view the code YOU write as such at all times and be thinking about how it might be reusable, cleaner, etc. for everyone else who has to work with it in the future.

Turning back to ReSharper.  It's such a gem in that it clearly points out unnecessarily code in every class and every line of code in that class.

There's no reason if you have ReSharper installed that you aren't by habit removing unnecessary code as you come across it, which is part of the boyscout rule, keeping the code campground clean.  As you know the boyscout rule that so many great teams abide by is that every time you check in code, it should be a little better than what it was before you check it in.  Robert Martin's Clean Code book emphasizes the boyscount rule.

When you are in a class and you have ReSharper installed, this stuff just screams out at you.  And for me it's just a habit to remove it.  It feels gross to have it in here...and you should feel the same way.  It takes up no more time doing this;  It does not slow me down as it's just a few seconds to remove this stuff as you go and as you see it elsewhere in an entire class.

Look at these examples where ReSharper has pointed out/grey out unnecessary code (I pointed it out with yellow here):

unused usings

unecessary "this." where there is no object type conflicts whatsoever

unecessary Fully Qualified Types where you should have added a using statement

unnecessary explicit conversions:

unnecessary chatter:

unnecessary default assignments at times

Would the examples above give you "code itch" if you knew about them?  It's very much code smell, and it really should make you itch if you truly care about keeping your code base clean.

Why should we removed this stuff? for READABILITY, simple as that.  And having more readable code leads to easier maintenance for all.  Don't be lazy, get rid of it NOW while you are working in that class before you check it in.  ReSharper makes it stupid easy and quick do do this, and It's part of being a professional Software Engineer to keep this clean.

One of the things I do just by good habit right off the bat is when I make a new class in C#, I immediately remove the default usings that are generated at the top as initially they are unused anyway.  half the time you won't end up need a lot of them once you are done with the class anyway.  ReSharper will simply hint and allow you to add using statements quickly and easily anyway when it detects you need them.  So start off with a nice clean template is what I highly suggest so that this stuff is removed initially to start with.

Now you may be thinking "hey I like to show things explicitly to make code more readable". You know what?  you're actually making it less readable.  For instance if you think you still need to do something like establishing a variable with default such as int someVariable = 0; and you know though in certain cases you don't need to explicitly show that you're setting it to zero.  Seriously, stop over thinking and just get rid of it.  It's like the same with commented out code, get rid of it, it's clutter.  99% of the time you'll never use that commented code again.

ReSharper's Marker Bar

Now another thing that people who have even used ReSharper for a while don't know about or notice which for me is an awesome feature is  the Marker Bar.

When you open a class, look to the right.  ReSharper outlines problems, hints, or suggestions in code making it very easy to see an overview of your class in terms of code quality and errors that exist:

And all you have to do to get to that line of code that is a problem is to click on that colored bar on the right.  

ReSharper shows different colored bars to the right to point out different things:

Don't you love that?  In fact there was a team I worked with who decided that a good standard for the team as part of cleaning up code would be to check this in every class you've made changes to BEFORE you check in the code.  

So get rid of unnecessary code or use the hints to make the code more compact, do it, then check it in.  You start to view your classes different with this feature too.  Because when you open classes, you start to look to the right automatically and it just becomes a habit to use this feature to see if you can clean something up before saving your code and checking it in.

This just touches the surface in how ReSharper can help a team keep code consistently clean and uniform.  There are many more features that I'd like to resurface later in a future blog post.

While most ReSharper users already know about this, there are plenty of developers who have never heard of a tool like ReSharper, refuse to use it, or don't understand some of its benefits.  So I like to resurface some of this stuff once-in-a-while hoping a newbie finds out about ReSharper and some great stuff they and their team are missing out on.