Using Resharper -- is it really a "personal decision"?

Question

My team lead recommends that all the developers user ReSharper but he does not "enforce" this recommendation. As a result, whenever I open some code it immediately jumps out to me whether the developer who wrote it used ReSharper or not. Tell-tale signs are unnecessary nesting, use of redundant type declarations and generic parameters, typos in symbol names (because it would be too hard for them to fix them), etc.

The unstated assumption seems to be that the user of ReSharper is a "personal decision" that does not affect anyone else. But is this really true? What level of "enforcement" on this issue is ideal?

Answer 1

If you work in a group, then nothing that affects your code is purely a personal decision.

Answer 2

After using R# for over 2 years now, I sympathize with you. I find my code substantially cleaner, terser and more readable. And my standards, for my own code as well as for the code I have to review/maintain from others, have taken a quantum leap upwards. However, a fundemental rule of politics (human nature really) is that most people resist change... and forcing it upon them never seems to lower that resistence, so persuasion is always a better approach...

Answer 3

<Opinion>

I think the use of tools like ReSharper should be determined the same way style conventions are implemented. Everyone does it. Or no-one does it.

It's really annoying as a developer having hundreds of warnings from other developers who just didn't write to the same standards as everyone else.

</Opinion>

Answer 4

You should write code that conforms to the coding standards agreed on by your team (something like this is sufficient). Your choice of VS plugins, keyboard bindings, font colours and sizes should remain your own.

I wouldn't get overly worked up about minutae such as "redundant type declarations". More important to get people on board with the SOLID principles.

Answer 5

Personally, I think that standards on a team work best if they are enforceable, and enforceable via a tool. Resharper does a good job (provided you setup the same rules) of giving warnings on files for formatting differences. Rules only matter if there is a tool that enforces them - whether that's Resharper's warnings, or something else doesn't matter so much.

My current team is about half-and-half. I use R#, as do a couple other members, but some of our team just uses VS without it. We do, however, enforce that we all follow the standards provided by StyleCop, though - so the R# users are happy (provided we have StyleCop for Resharper installed), and the non-Resharper users can work fine.

Answer 6

I think that tools should be used by the whole team in order to be effective.

Having said that it seems that the "problem" you've encountered is a code quality issue and not related to R#. The mistakes you describe can be created with or without R# and could be avoided by either performing code reviews or pair programming.

R# help write good code faster and I can't think of a developer that doesn't want to inrease his productivity - so if you want everyone in your team to benefit from R# convince them that they'll be more productive using it. Again pair programming is a goidd way to demonstrate the merits of a new tool.

Answer 7

It's best to use a consistent set of rules across a team/project, regardless of how they are enforced (by a CA tool or code reviews, etc).

In the absence of a clear standard on a given point, you need to relax your rules (or resharper's) to accept things that other programmers do, even if they don't fit your personal style. Indeed, programmers are all individuals and you will never find two such people who do things exactly the same - some flexibility is always needed.

CA tools often make time-wasting suggestions (the majority of suggestions are pretty rubbish in my experience). What I mean is that if all the members on your team can effectively read, understand, and maintain a piece of code as it is written, then there is often little point refactoring that code - beware of wasting time trying to satisfy Resharper when the changes you are making aren't going to really make any difference to the readability, maintainability, robustness, portability, or efficiency of your code. Turn off these warnings rather than wasting time refactoring your code.

Having said that, you should definitely campaign and promote CA to your team and your manager. The team/project will benefit, and everyone will personally benefit from the use of CA tools.

Answer 8

To me using a code refactoring tool is a no-brainer. Think about it--you are not writing code for yourself, you are writing it for others :) Architects have to make their plans precise, readable, and understandable because they know someone else is coming behind them. They have tools that help them do this. Why, then, do programmers not do the same? We complain it's "too much work" or "Why fix what works?" The truth is that not refactoring boils down to pure laziness.