I use Resharper at work. Some of my colleagues do not.
When I open some code that has been written someone who doesn’t, it is immediately obvious by the amount of orange on my screen.
What I am unsure of is to what extent I should feel free to tidy up the messes the have unknowingly left. With most of what I am looking at, it is sloppy but harmless, and wouldn’t really jump out at me if I hadn’t ever used Resharper.
I guess I see my options broadly as
1) The history of changes to source code is essential to maintenance. Change as little as possible, or the next guy wont have a hope of figuring out what has changed. Who cares about unreachable code, unnecessary use of .ToString() etc. anyway.
2) Change the meaningless stuff like includes, fix method documentation comments and things like that. The guy who wrote it likes his code to look like this, so leave it in a state where he wont complain, but get rid of some of the unnecessary orange
3) Orange is just red but lighter. F12 then Alt+Enter until green.
4) Forget the orange, look at that monster 700 line function. What is this 1997? Time to get busy… and if you have got the time, introduce your colleague to our good friend and mentor Mr Fowler.
I tend to flit between the options depending on how much time I have got, to what extent I am now responsible for the code, and how complex the code looks (which can make me go for 1 or 4 usually).
It seems like one of the 4 options should be the one I am striving for though, but I have no idea which one
It’s the boyscout principle. If it’s “their” code and they maintain it then introducing little cleanup-changes shouldn’t offend them, but going too far might seem rude or you might be effectively taking ownership of the code.