Code Quality test with Continuous integration

Last time I wrote about what is code quality and how to measure. Today it’s going to be an implementation of code testing with opensource and continuous integration with Jenkins.

The concept is test code from the following tools and executes to xml and show the result from Jenkins plugin.

Code we have are:

C-code (from Eclipse)

Code Metrics

Tool: CCCC http://cccc.sourceforge.net/

Jenkins Plug-in: Jenkins CCCC Plug-in https://wiki.jenkins-ci.org/display/JENKINS/CCCC+Plugin

A free software tool for measurement of source code related metrics. The CCCC tool was developed as a testing ground for a number of ideas related to software metrics.

Report: This table shows measures over the project as a whole.

• NOM = Number of modules
  Number of non-trivial modules identified by the analyser. Non-trivial modules include all classes, and any other module for which member functions are identified.
• LOC = Lines of Code
  Number of non-blank, non-comment lines of source code counted by the analyser.
• COM = Lines of Comments
  Number of lines of comment identified by the analyser
• MVG = McCabe's Cyclomatic Complexity
  A measure of the decision complexity of the functions which make up the program. The strict definition of this measure is that it is the number of linearly independent routes through a directed acyclic graph which maps the flow of control of a subprogram. The analyser counts this by recording the number of distinct decision outcomes contained within each function, which yields a good approximation to the formally defined version of the measure.
• L_C = Lines of code per line of comment
  Indicates density of comments with respect to textual size of program
• M_C = Cyclomatic Complexity per line of comment
  Indicates density of comments with respect to logical complexity of program
• IF4 = Information Flow measure
  Measure of information flow between modules suggested by Henry and Kafura. The analyser makes an approximate count of this by counting inter-module couplings identified in the module interfaces.

Code analysis

Tools: http://cppcheck.sourceforge.net/

Jenkins Plug-in: Jenkins Cppcheck Plug-in https://wiki.jenkins-ci.org/display/JENKINS/Cppcheck+Plugin

CPPcheck is a static analysis tool for C/C++ code. Unlike C/C++ compilers and many other analysis tools it does not detect syntax errors in the code. Cppcheck primarily detects the types of bugs that the compilers normally do not detect. The goal is to detect only real errors in the code (i.e. have zero false positives).

Report:

• Out of bounds checking
• Check the code for each class
• Checking exception safety
• Memory leaks checking
• Warn if obsolete functions are used
• Check for invalid usage of STL
• Check for uninitialized variables and unused functions
• http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page

C# code (from Visual Studio)

Code Metric

Tool: CCM http://www.blunck.se/ccm.html

Jenkins Plug-in: CCM Plug-in https://wiki.jenkins-ci.org/display/JENKINS/CCM+Plugin

CCM is a tool that analyzes c/c++, c#, javascript and Typescript code and reports back on Cyclomatic Complexity, a metric introduced by Thomas McCabe back in the mid 70's.

This metric states the number of independent linear paths through a unit of code and is useful to determine how complex the unit of code is (for this particular tool, a unit is a function or a method).

Report:

• Cyclomatic Complexity metrics

Code analysis

Tool: FxCop www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=917023f6-d5b7-41bb-bbc0-411a7d66cf3c

Jenkins Plug-in: Jenkins Violations plugin https://wiki.jenkins-ci.org/display/JENKINS/Violations

FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements. Many of the issues concern violations of the programming and design rules set forth in the Design Guidelines, which are the Microsoft guidelines for writing robust and easily maintainable code by using the .NET Framework.

Report:

FxCop is a tool that performs static code analysis of .NET code. It provides hundreds of rules that perform various types of analysis.

• Design
• Globalization
• Interoperability
• Maintainability
• Mobility
• Naming
• Performance
• Portability
• Reliability
• Security
• Usage

What make Quality of Code/ How to measure?

To make sure that your code is well running together with the other, you might need to have standard or tools that you and your team could work

Code Metrics

Code metrics is a set of software measures that provide developers better insight into the code they are developing. By taking advantage of code metrics, developer can understand which types or methods should be rework or have more tests.

There are some common measures that we could use;

•           Total line of code
•           Line of duplicate code
•           Unit test coverage
•           Coding standard violation
•           Program execution time
•           Program load time
•           Ratio of comment and code

Code Standard

MISRA-C is software development standards for C programming language develop by MISRA (Motor Industry Software Reliability Association). Many developers from embedded systems specification always refer to MISRA C Standard for the work that needs high reliability.

MISRA also has more users outside the original specification. They realized that in many areas of an automobile design, safety, portability and reliability is importance. They has evolved as a widely accepted model for best practices by leading developers in sectors including aerospace, telecom, medical devices, defense, railway and others.

The result was a set of “Guidelines for the use of the C language in Vehicle-Based Software” or “MISRA C”. The first published guideline comprises a 70-page document that describes a workable subset of C to avoid many of well-known problems. The MISRA C document contains 8 chapters and 2 appendices and was obviously written by experienced embedded programmers. Chapters 1 through 6 contain important information about the rationale for MISRA C and how to interpret the rules. These Chapters should be read prior to diving in to the actual rules, which are found in Chapter 7. MISRA C document is available at www.misra.org.uk for about $50.

Quality of Code

There are many definitions for Quality of code from my research this few days. As we know, we try to improve our code, not only for the author but also other people in the team. If I could list what are the good code should be, it should be like this;

• No redundant or repeat code: if you have several lines of code with the same action, you should make it to the new function. For this advantage, you will have another short command that can reuse many times.
• Code readable 
• Use good name for function or variable
• Good comment and document
• But if you have a good code it should understandable without comment. Source code itself says what the code does and how

• Right responsibility for each function: one responsibility for one function.
• Optimize resource/efficient: Poorly written code will not take account of resource usage, for example it will not cache information it could cache, or it will create new objects when it did not need to. These issues lead to hard to maintain applications when deployed and used.
•  Well organized: should be easy to find what variable goes to which function, where you locate your code.
•  Have code review: ask some other person for each some important part