There is B::Xref, which claims to create cross-reference sections.
For class inheritance, I'm sure there is a module that lists you the tree, as Ovid uses fancy graphviz output in the paper, and I doubt he created that manually.
| [reply] [Watch: Dir/Any] |
I'd probably also like to find duplicate pieces of code.
You could hash all code lines and compare à la Eric Raymond.
--
No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]
| [reply] [Watch: Dir/Any] |
This is, un-fortunately, one of those cases where “TMTOWTDI” can turn-around and bite you in the (!). There are many syntactically-different ways to express the same meaning in terms of source-code, and when you say, “are very similar,” you unfortunately (probably) mean, “means, or does, the same thing.” And that kind of analysis ... which BTW I have done many, many times ... requires “the human eye.”
I happen to have more-than-trivial knowledge of the arcane arts of “source code analysis,” having worked for an early-90’s startup that tried (in vain...) to do this sort of thing with COBOL. (They went public anyway, then of course went bust.) You can map out data-dependencies and control flows (as I have myself done recently, in another Meditation), but you cannot discern meaning.
Certainly, you can automatically scan source-code to build up a data-dictionary and a code-dictionary ... and this, for an app that might involve many hundreds or even thousands of source-components, can certainly be useful. These undertakings very quickly outstrip the limits of human visualization, even for the most spectacular of totally self-absorbed nerds.
| [reply] [Watch: Dir/Any] |
Finding code snippets that mean the same even though written differently would be of course super awesome but for now I would be happy to locate instances of "copy-paste development".
| [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |
I've found that running the code through perltidy (using the same format) is a good idea, it will transform code to be uniformly formatted. That way, whitespace differences etc are eliminated as a source of difference between two pieces of code. Obviously, you should run the perltidy script before any other systems that searches your codebase for duplicate code or near-duplicate code. Using perltidy will improve the false-positive rate of the other systems.
(You can even enforce a uniform coding format by using perltidy with the available hooks in source control products, but that's a different subject) | [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |