views:

885

answers:

9

ReSharper Code cleanup feature (with "reorder members" and "reformat code" enabled) is really great. You define a layout template using XML, then a simple key combination reorganizes your whole source file (or folder/project/solution) according to the rules you set in the template.

Anyway, do you think that could be a problem regarding VCS like subversion, cvs, git, etc. ? Is there a chance that it causes many undesired conflicts ?

Thank you.

+2  A: 

It can definitely cause conflicts, so I would make sure you don't reformat entire files if there are people working on them in parallel.

Lasse V. Karlsen
+7  A: 

Yes, it will definitely cause problems. In addition to creating conflicts that have to be manually resolved, when you check in a file that has been reformatted, the VCS will note almost every line as having been changed. This will make it hard for you or a teammate to look back at the history and see what changed when.

That said, if everyone autoformats their code the same way (ie, you distribute that XML template to the team), then it might work well. The problems really only come in when not everyone is doing the same thing.

pkaeding
What I recommend in these situations is doing things in two parts. In one sweep you clean up the code and the in the second you make your changes. Two different commit messages. This way it's easy to undo what you did *and* know what to change with your fixes. Committing to too many things in a multiple commits is a good practice, in my opinion. Lets others know the what and why's *much* easier.
Nazadus
A: 

It definitely could cause conflicts.

If you want to use this in a multi-user environment then the configuration of Resharper needs to format your code to a set of standards which are enforced in your organization regardless of whether users make use of Resharper or not.

That way you are using the tool to ensure your own code meets the standards, not blanket applying your preferences to the whole codebase.

Sarcastic
A: 

I Agree with the previous answers that state that conflicts are possible and even likely.

If you are planning to reformat code then at least make sure that you don't mix reformat checkins with those that change the function of the actual code. This way people can skip past check-ins that are simple reformattings. It's also a good idea to make sure that everyone knows a reformat is coming up so that they can object if they have ongoing work in that area.

Simon Steele
+2  A: 

I'm waiting for an IDE or an editor that always saves source code using some baseline formatting rules, but allows each individual developer to display and edit the code in their own preferred format. That way I can put my open curly brace at the beginning of the next line and not at the end of the current line where all you heathens seem to think it goes.

My guess is I'll be waiting for a long time.

+2  A: 

You can use StyleCop to enforce a comprehensive set of standards which pretty much forces everyone to use the same layout styles. Then all you need to do is develop a ReSharper code style specification that matches this, and distribute it to the team.

I'm still waiting for someone else to do this, and for JetBrains to clear up all the niggling details which aren't fully supported, in order to allow ReSharper to basically guarantee full StyleCop compliance.

Daniel Fortunov
+2  A: 
  • Just reformat the whole solution once
  • AND make sure that every developer is using Resharper
  • AND make sure that formatting options are shared and versioned (code style sharing options)
Rinat Abdullin
A: 

We're working on something to work with refactors at the source code level. We call it Xmerge, and it's now part of Plastic. It's just a first approach, since we're working on more advanced solutions. Check it here.

pablo
A: 

It might be a good idea to write a script to check out every version in your source control history, apply the code cleaning, then check it into a new repository. Then use that repository for all your work in future.

rjmunro