Code Analysis via Version Control HistoryJustin Mclean Class Software

Email: justin@classsoftware.com Twitter: @justinmclean Blog: http://blog.classsoftware.com

Who am I?

• Programming for 25 years

• Developing and creating web applications for 15 years

• Apache Flex PMC, Incubator PMC, Apache member

• Release manager for Apache Flex, FlexUnit, Tour De Flex, Squiggly

• Run IoT meetup in Sydney Australia

In the last 40 years we have written billions of lines of code that will keep programmers employed for trillions of man hours in the next few thousand years to clean up this mess we’ve made.

Joe Armstrong

The Mess We’re In

Your Code as a Crime Scene

You Write Code?

• 40-80% of all code is maintenance

• This is difficult and expensive

• More so with agile methodologies and on successful systems

• How to make this effective?

• Primary goal is to understand existing code

• All code is legacy code

Detecting Issues With Code

• Code reviews

• Pair programming

• Unit Tests

• Continuous Integration

• Static code analysis

• Complexity metrics

Scalability

• What about large code bases?

• How do you decide what to work on?

• How to work out where the bugs are?

• What bugs are important?

Code Visualisation• Can you visually represent code to get a better

understanding of what’s going on?

• Code Cityhttp://www.inf.usi.ch/phd/wettel/codecity-wof.html

• Make a city of each class arranged by packages in city blocks

• Height is number of methods, colour coded by no of lines and area by no of terms

Code City

Code City Limitations

• Supports only a few common languages

• Shows hotspots (large buildings) but no real indication of where to possibly spend effort

• Existing hotspots may be stable

• Missing an important dimension

Version Control History

• VCS contains a lot of useful information - that we mostly ignore. Information like:

• Who changed what lines when

• How much and how often things change

• Can aggregate information to tell us something useful?

Why code Changes

• Fixing bugs

• Refactoring poor design

• Poor understanding of the problem

• Change frequency == proxy for effort

• Code that changes in the past is likely to change again in the future

Effort + Complexity

• Change frequency / effort is not the whole story

• Config files changes frequently

• Overlaps in effort and complexity gives possible hotspots

Code Hotspots

• Hotspots are code where changes will give the most benefit

• Frequent changes to complex code indicate poor quality code

• Lots of study in this area and surprisingly simple complex measures (change frequency) perform just as wells more complex measures

What use are Hotspots?

• Take cognitive biases out of the equation

• Where you bugs are likely to be

• Prime areas for code reviews

• Prime areas for refactoring

• Targets for extra testing

Code Maat

• Performs various analysis on version control history

• Produces simple csv text files

• Supports parsing git, svn, hg VCS

• Open source (GPL)

• https://github.com/adamtornhill/code-maat

Producing HotSpot Data• Clone git repo

• Work out time period

• Generate git log summary data

• Look as summary

• Generate change frequencies

• Generate code complexity metrics

• Combine change frequency + complexity

Apache Flex Project

• Large code baseNo files = 25000,LOC = 5 million or about 20 million including tests

• Mix of many file types and languages MXML, ActionScript, Java, XML files

• Two distinct phases - before and after donation

statistic,valuenumber-of-commits,30090number-of-entities,4672number-of-entities-changed,34916number-of-authors,18

Adobe Flex SDK Summary

statistic,valuenumber-of-commits,2911number-of-entities,51505number-of-entities-changed,81012number-of-authors,55

Apache Flex SDK Summary

Complexity

• LOC is a terrible complexity measure, but turns out it’s just as bad as most others

• Fast and simple

• language agnostic

• CLOC

• https://github.com/AlDanial/cloc

module,revisions,codebuild.xml,139,1481frameworks/build.xml,57,423mustella/jenkins.sh,48,167mustella/build.xml,44,1988ide/checkAllPlayerGlobals.sh,35,85frameworks/projects/mobiletheme/defaults.css,34,1568modules/downloads.xml,34,384installer.xml,29,821frameworks/projects/spark/build.xml,28,231frameworks/projects/textLayout/build.xml,28,218frameworks/projects/framework/src/mx/collections/ListCollectionView.as,28,1442

Apache Flex SDK Revisions

Hot Spot Confirmation

• Build files

• Mobile theme

• ListCollections

• DataGrid and AdvancedDataGrid

• DateField

Hot Spot Limitations

• Just numbers - may need to normalise

• Time period may be hard to get right (hotspots move)

• Impacted by individual commit styles

• May have false positives

• Just a guide - but still a very useful one

Visualise Hot Spots• Hard to understand a large amount of

information

• Classes are nested in packages and we have complexity and change frequency / effort

• Circle packing works well. Circle size is LOC, colour by change frequency.

• D3.js easy to use / can display easily

• Need CSV -> JSON conversion

Apache Flex SDK

Apache Flex SDK

Apache Flex SDK

Apache Flex SDK

Hotspot Analysis

• Hotspots are small proportion of all code

• Configuration files vs complex application logic

• Can have false positive - need to confirm

Hotspot Analysis

• Experimental area

• 3rd party modules

• Compiler

• Data grids

• support classes

Complexity (again)

• LOC OK but is there something better?

• Whitespace indentation!

• Easy to calculate / language independent

DataGrid.as complexity• CLOC shows 50/50 split between code and

comments with 2800 lines of actual code.

• May be good idea to remove comments?

• DataGrid.as whitespacen,total,mean,sd,max 5860,9244,1.58,1.21,13

• Mean is low, sd is low, but max is way too high

• Real hotspot

rev,n,total,mean,sdf52eb16,5608,8816,1.57,1.230c4290c,5609,8816,1.57,1.2363580a8,5644,8856,1.57,1.23fa2108b,5644,8856,1.57,1.23abc381b,5644,8856,1.57,1.23774cdd7,5791,9061,1.56,1.225e6e5c3,5791,9061,1.56,1.224388da8,5791,9061,1.56,1.22ec1ac28,5810,9090,1.56,1.2222b68de,5839,9124,1.56,1.22b1d0359,5855,9164,1.57,1.221bef097,5851,9158,1.57,1.223e752d9,5854,9165,1.57,1.226c53962,5857,9172,1.57,1.22c47f9f9,5855,9169,1.57,1.22bb600fd,5855,9169,1.57,1.2271f8757,5853,9230,1.58,1.213a1769b,5860,9247,1.58,1.218767c20,5860,9244,1.58,1.21

Complexity Trend

Temporal Coupling

• File that need to change at the same time

• Causes:

• Copy paste duplicated code

• Inadequate encapsulation

• Anti-pattern sometimes referred to as shotgun surgery

Detect Temporal Coupling• Results are a bit noisy - may need to filter

frameworks/projects/framework/src/mx/states/AddItems.as, frameworks/projects/spark/src/spark/components/Group.as, 92,7frameworks/projects/framework/src/mx/states/AddItems.as, frameworks/projects/mx/src/mx/core/Container.as, 83,6frameworks/projects/mx/src/mx/core/Container.as, frameworks/projects/spark/src/spark/components/SkinnableContainer.as, 83,6frameworks/projects/framework/src/mx/states/AddItems.as, frameworks/projects/spark/src/spark/components/SkinnableContainer.as, 83,6frameworks/projects/mx/src/mx/core/Container.as, frameworks/projects/spark/src/spark/components/Group.as, 76,7

Just Words?

Knowledge Map

• Generate ownership of files

• Multiple owners per file imply more potential bugs

• Knowledge maps - who know most about which files

Apache Flex SDK

Apache Flex SDK

What we have learnt• Lot of useful information in your version

control history waiting to be found out

• Technique scales easily to (very) large code bases

• Keep data formats simple

• Simple measures of effort and complexity are often as good as complex ones

• Can find out areas in need of attention in your code base

Links• Code as a crime scene

https://pragprog.com/book/atcrime/your-code-as-a-crime-scene

• Code City http://www.inf.usi.ch/phd/wettel/codecity.html

• CLOChttps://github.com/AlDanial/cloc

• Code Maat https://github.com/adamtornhill/code-maat

Ask now, see me after the session,follow me on twitter @justinmcleanor email me at justin@classsoftware.com.

Slides can be found at conference site.

Questions?