4. Why Visualizing Code?
• A way to:
• Represent a lot of information in a
small space
• Choose starting points in an unknown
code base
• Facilitate code comprehension
6. Limitations
• Visualizations are interpreted by
humans
• Unfortunately we are the limiting factor
• Limited color choice
• Limited information density
7. Limited Color Choice
• We must avoid:
• Colors too close to each other
• Too many colors (7 max)
8. Information Density
• Too much information renders it useless
• Harder to locate a precise information...
• Like finding a needle in a haystack
10. Microprint Assumption
• It is easier to merge information than to
sort it
• It is easier to merge information than to
sort it
• It is easier to merge information than to
sort it
• It is easier to merge information than to
sort it
11. • So we reduce and stack each view:
It is easier to merge
information than to
sort it
It is easier to merge
information than to
sort it
But We Do Not Have
That Much Space!
It is easier to merge
information than to
sort it
It is easier to merge
information than to
sort it
12. Microprint Principle
• Several views of a method via a variant
of code highlighting:
• Variable access
• Control flow
• Object interactions
• Code and frequency coverage
13. Advantages of the
Approach
• Several focused views
• Few information in each view
• Few colors as well
• Colors can be reused in several views
19. First: Some
Implementation Details
• Microprints use the Refactoring Browser:
• RB parser, AST and visitor
• Microprint = color to marker mapping
• Markers = visitors of RB ASTs
• Looking for “interesting” nodes
21. Create Your Own
Marker
• Define a new visitor
• When an AST node is interesting:
• self mark: aNode (boolean)
• self mark: aNode value: v (integer)
• If you want to store a metric
23. Conclusion
• Merging information...
• Is easier than sorting it
• Microprints:
• Several semantic views of methods
• Integrated in VW and CodeCrawler
• Customizable and extensible