Why don't many code review tools seem to be syntax aware or provide more in-depth analysis of changes? Is it simply too hard to do?

I find this to be a major hole of most programmer's toolkits. From what I have seen, which admittedly is not much, code review tools just compare code line-by-line with many of them not even being able to do syntax highlighting.

Is there a solution out there that is smart enough to offer file-level, method-level code review/comparison? One of the simple problems I have is that methods get re-ordered in code and my code review software breaks down completely, but they should be able to do so much more.

I'm interested in others opinions/knowledge on the topic of code review/comparison tools.

  • 1
    I definitely think there is a market for tools that work at the level of the abstract syntax tree, e.g. code manipulation, highlighting changes... The skills needed to write parsers and understand the underlying structure of code may have been lacking, but it seems the advent of intellisense and refactoring tools in mainstream IDEs have changed that.
    – Joh
    Sep 17, 2011 at 8:14

4 Answers 4


Code review tools are tools designed to be used with any programming language.

This means that in order to add file-level and/or method-level comparisons, they will need to understand the context of the language.

This in turn means both knowing about all possible languages and having a parser for them.

All of which are very difficult and error prone. So, for a commercial enterprise the question would be - which language to support first. How well? For a free option, the fact is that such a thing will take a very long time to do, even for one language.

Having a line-by-line option covers most needs already, so people don't try more.

  • 1
    Just my opinion. There should be tools that parse source files of a particular language and emit a marked-up file which tags each token or symbol with their type and identity. A code review tool can then display the text part, and use the additional markup info for source line matching and highlighting.
    – rwong
    Sep 16, 2011 at 19:22
  • @rwong - But first, the code review tool would need to determine the language. This might not be trivial, depending on the contents of the file, the language in question and file name.
    – Oded
    Sep 16, 2011 at 19:24
  • The parser tool will have to be bought separately.
    – rwong
    Sep 16, 2011 at 19:36
  • 1
    I have to disagree completely, it's really not a difficult problem. This site and stackoverflow use prettify - a simple syntax highlighter in Javascript that makes good guesses on which language is used. When it can't find a good match, it doesn't highlight. Sep 16, 2011 at 19:43
  • 1
    @Oded Syntax aware editors are common these days. Every IDE has one, and stand-alone text editors such as Notepad++ have no problem handling multiple languages. So it shouldn't be that hard to have a file comparison tool that is also syntax-aware.
    – Simon B
    Apr 9, 2021 at 9:50

A solution (that we might be able to test soon enough built-in in VS) is a deep integration within the IDE. the IDE is already able to do all the things you are considering as missing or not working actually :

  • Syntax awareness
  • Project hierarchy for file operations
  • Data structure map for moved code matching

The downside, is that such tool will be binded to the languages supported by the IDE, and as such could limits its universality.

There are already some plug-ins for different IDE available. I didn't tested them, but provide link for examples of existing solutions :

Jupiter - Eclipse (SO Related Question)

TeamReview - TFS / VS

  • Jetbrains suite of products have pretty good diff viewers and good git integration in my opinion.
    – Adam B
    Jul 9, 2022 at 1:16

The problem seems to be that not much many can be made. And that there are many languages, and many other uses.

Right now I could do with a diff tool that compares log files. Here’s some problems: These log files contain references that are different in each log file, creating 100s of pointless differences that should be removed. Some lists are produced in random order, like file a, b, c, d in one log and b, c, a, d in another. There are systematic differences. I would just want to see ONCE “whenever file 1 contains xyz, file 2 contains abc.

Well, it’s a bit difficult. And nobody does it.

Here’s a stupid one: In some C files, every function has a comment header. The first two lines of comment headers ar always the same. So if I insert function A before B the bloody diff tools match the first two lines of the function headera of B and A, then show that the rest of As header plus the A function plus the first two li es of Bs function header were inserted, then everything starting from line 3 of Bs function header matches. Quite awful.

But the worst are JSON and other files containing dictionaries which are written out in random order. With two practically almost identical dictionaries having no similarity at all.


The simple answer is, that a code review could become unwieldy: this function is moved elsewhere but at the same time some other changes were made. Only syntax-highlighting would be nice to have in a diff.

There were (are) some version control systems that would recognize

  • a rename;
  • a moved function body.

With code review presenting these changes is hard for a human and some of the changes may be overlaid, renaming + moving. So such a "better" version control with rename and remove steps never became popular. A pity, maybe in some future with undo/redo of refactoring steps.

For such semantic meta-information code review must rely on commit messages of hopefully many small commits (and not a single large commit as is usual), or do commit with peer review, so the original committer can immediately learn something, corrections can be made, and the reviewer can ask or get informed.

What goes a bit in your direction, is that the reviewer should do a code style checker, like SonarList, detecting new or side-stepped issues. With SonarQube integration one could check the statistics for some deterioration.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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