I am trying to infer the differences between two projects, however so far it has been really painful, because one of the parties has done auto-formatting on the code.

Basically, this makes a merging tool like meld find many differences because the spacing in one of the projects has changed.

Is there another way to compare two projects which are similar, by ignoring syntactical changes.


One option to reduce the number of differences meld shows is to use the Text Filters.

Navigate to: edit --> preferences --> text filters and check:

  • ignore changes which insert or delete blank lines
  • c++ comment
  • all whitespaces

and you can add custom filters, for example, to ignore {, }.

How "healthy it is to do this, I don't know...

  • 6
    did you consider auto-formatting both projects in the same way prior to feeding to diff tool? make "canonical" form so to speak – gnat Apr 10 '16 at 18:00
  • That is one option indeed, but if I do that, I will be changing the formatting of a legacy code, and will have further difficulties when trying to merge my project to the original one. – Kristof Pal Apr 10 '16 at 18:05
  • What kind of diff tool are you using that doesn't have an "ignore whitespace changes" mode? – Kilian Foth Apr 10 '16 at 18:22
  • meld; it does support it, and I applied as you can see in my edit from 27 minutes ago – Kristof Pal Apr 10 '16 at 18:37
  • @KristofPal I would think that if your original project is also formatted, you'll have those merge problems anyway? – Ben Cottrell Apr 10 '16 at 19:07
  1. Make a copy of the legacy code so you don't modify the original, let's call it "Project A".
  2. Apply the same auto-formatting to "Project A".
  3. Let's call the code that your coworker autoformated "Project B"
  4. Compare "A" and "B".

One brutal possibility is that you just reject the new code. Gratuitious changes like that are an absolute pain for the reviewer. I mean, it's not your fault. The worst thing is when two developers use different auto formatting, so you will have the same thing again and again. Different auto formatting methods are just absolutely not acceptable if you want to do code reviews.

You then have two choices. You can make an intermediate change to the project that consists solely of autoformatting. Instead of reviewing, you have another person doing the exact same change and check whether your code ends up formatted in exactly the same way. One is committed, one is thrown away. The guy with the autoformatted code can/must rebase to this, and now you can review. Everyone else should also rebase their code in time.

All in all, a major pain.


There are two ways of solving this problem, if you want to automate the comparison of the code. This problem often occurs when assessing the programs produced by students in class, for example. Two students have similar programs and attempt to obfuscate this by re-formatting.

You can convert both versions to a neutral common format by putting a copy of each of them through the same re-formatting tool (of your choice) and then compare the resulting files, which will now be identically formatted. This only works if only the layout has been changed. If substantial changes have been made to commenting or entity naming then a more technical method has to be used.

The method employed is to parse each of the versions and compare the intermediate code. There are tools for this. One such tools (available in open source) is (JPLAG). Other tools are available.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.