In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this.
In addition to methods, this kind of navigation can also be applied to:
- Macros (C preprocessor) (and possibly show their expanded versions upon mouse hover)
- SQL tables and fields
- Labels (and their associated GO TOs)
SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code.
Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature.
It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis.
Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code.
This knowledge should also be transfered from SSLR to Sonar.
A possible way to implement this would be to annotate the original source code with some metadata, for example using a kind of XML.
could be sent to Sonar, after being analyzed by SSLR, as:
In the example above, the following tags were used:
More tags could be required, for example to handle conditional compilation, code margins (PL/I and COBOL), preprocessing directives, etc.
From there, Sonar should be able to generate the links on the fly to enable the navigation, and also to highlight the source code properly.
The details about the format are yet to be defined.
For example, should SSLR tell Sonar which resource key to open and at which line, or should it tell Sonar to open a method with a given signature (as shown in the example)?
A more compact representation could also be needed in order to limit the database storage requirement overhead.
The raw, original source code can be easily reconstructed by removing the metadata tags.
Or, we could also decide to store this additional metadata alongside the raw source code.
With the metadata, it also becomes possible to create a Javadoc perspective, to only show the Javadoc and not the source code.