Project

General

Profile

Code analysis process and tools » History » Version 4

« Previous - Version 4/14 (diff) - Next » - Current version
Ruth Pordes, 05/05/2016 01:37 PM


Code analysis process and tools

The current proposal for code analysis is as given in slides at the steering meeting

Summary of process to date

The goal is to invest resources to manage risk in order to:

  • Reduce overall cost of execution, support and evolution
  • Avoid excessive resource utilization from poor programming practices.

Lack of compliance with architecture and/or design guidelines make it costly to maintain code and make it difficult to later adapt code to meet the existing or new physics goals. Bad coding practices reduce the utility within the software suite by needlessly limiting the potential scope of a module. (For example, these costs can appear suddenly when a new requirement / opportunity arises).

Effort will be committed prior to the actual review to implement any agreed upon recommendations. Reviewers will be available for consultation during this phase.

Tracking the progress of the implementation will happen through the usual Redmine Issues tracking system and the coordination (and if needed architecture) meetings.

Lessons learned and best practices will be added to existing documents/training materials (make a pointer here) and ideas for evolving the tools and knowledge for developers to write better code is an additional goal.

A further goal is to help train more people to become review leads.

Outline of Code Analysis

  • Discuss the process
  • Run selected performance and code analysis tools on the modules
  • Look at the code
  • Review the output of the analysis tools
  • Make recommendations as Redmine issues
  • Modify documentation of the process
  • Discuss the outcomes and complete reporting

Scope

  • Modularization, design, interoperability
  • Data products – recommendations, lacks
  • Technical aspects of the code especially those that impact physics () and infrastructure performance (memory, cpu, etc). 
  • Usability, effectiveness of tools to help
  • Documentation - including that generated by doxygen.
  • Application of some tools to the code