Know differences of two code versions with very different formatting

I have two files from a C program. I guess both belong to quite the same version. Using "diff" I could know where the differences are, which probably consist in 3 lines. The problem is that the second file was given to another programmer which used a completely different indetation, parentheses style, etc, but probably only change those 3 lines which I need to开发者_C百科 find. If I use "diff" I get a lot of differences. So my question is, how could I in this situation know where the differences are, in terms of code. I tried to apply the same formatting to both files and then use "diff", but it does not work in my case.

---

Use a pretty-printer to format both files, and then do the diff.

---

You could use our SmartDifferencer program. It compares two code files by parsing them with a real parser (making it completely independent of formatting and placement or changes to comments), comparing the syntax trees, and then reporting the changes in terms of editing actions (copy, move, insert, reame-variable-within-block) that explain what occurred. So you see differences in terms of langauge structures instead of lines, which often produces much smaller diff results. It even ignore changes in number radix and string escapes, if the actual literal values are the same.

For languages such as C# and Java, this works extremely well. C is bit more problematic, as people write abusive C code that can't be parsed without knowing all the defines and #includes, etc. So it won't process some files and you'll to fall back on conventional diff perhaps augmented with a formatter as another author suggested, but that will still only give you line diffs. C++ arguably has the same problems as C, but in practice C++ code isn't nearly as abusive.

---

diff takes a -w option that tells it to ignore all whitespace when comparing lines. If, however, it is possible that one line from one file has been split into two or more lines in the other file, you are probably better off with @Jeff Foster's suggestion.