TOOLS: Continuous Code Quality | SonarQube

Continuous Code Quality | SonarQube

Quoting:
"Continuous Inspection. SonarQube provides the capability to not only show health of an application but also to highlight issues newly introduced. With a Quality Gate in place, you can fix the leak and therefore improve code quality systematically"

TOOLS: Parasoft C/C++test (Static Analysis)

https://www.parasoft.com/press/release-code-wizard/

Quoting [1999]:

"CodeWizard for C++ v. 3.0, the newest version of their automatic coding standards enforcement tool. CodeWizard offers serious developers and managers a solution for preventing errors during all stages of the development cycle. Development managers committed to delivering bug-free software have found CodeWizard a valuable tool because it helps keep down the number of errors that enter a project and saves time. CodeWizard acts as an automatic code reviewer that enforces a set of coding standards. Developers who follow coding standards can reduce the number of errors in their projects, as well as make their code easier to reuse, modify and maintain. The newest version of CodeWizard will be extremely useful to development managers because it now features RuleWizard, which allows users to quickly create custom coding standards. "Thankfully it is the code reviewer without the attitude," says Suzette LaGray, Senior Software Engineer at Siemens ElectroCom LLP. "It knows all the rules." Using patented Source Code Analysis technology (patent # 5,860,011), CodeWizard looks for coding standard violations. It automatically enforces over 70 coding standards that come from industry experts such as Scott Meyers and Stanley Lippman. With the addition of RuleWizard, development groups will be more successful at enforcing in-house coding standards. RuleWizard allows users to compose and modify coding standards (or "rules") by graphically expressing the pattern that they want CodeWizard to look for when it parses code. Rules are created by selecting a main "node", then adding additional elements to a flow-chart-like representation until it fully expresses the pattern that constitutes a violation of the rule. Rules can be specified by option, command line, or named rules"

Parasoft C/C++test - Wikipedia

Quoting:

"Parasoft C/C++test is an integrated set of tools for testing C and C++ source code that software developers use to analyze, test, find defects, and measure the quality and security of their applications. It supports software development practices that are part of development testing, including static code analysis , dynamic code analysis, unit test case generation and execution, code coverage analysis, regression testing, runtime error detection, requirements traceability, and code review. It's a commercial tool that supports operation on Linux, Windows, and Solaris platforms as well as support for on-target embedded testing and cross compilers."

TOOL: IBM Rational Logiscope (Static Analysis, Dynamic Testing)

FFR:

IBM Rational Logiscope is (amongst other things) a static analysis tool for C, C++, Java, and Ada.

Quoting:

"IBM Rational Logiscope tackles software quality head-on, providing a comprehensive suite of highly customizable static and dynamic testing tools to ensure that:

1. Latent bugs and faulty constructs are detected and eliminated
2. Software complies with required coding standards, whether they are personal standards, internal standards, or industry standards such as MISRA.
3. Complex and error-prone areas of code are identified at the earliest stage and corrective actions are taken.
4. Code review is automated and effort is focused on problematic area helping you adopt verification processes that are described by international standards such as SEI/CMMi, ISO/IEC 9216 and 9001, DO-178B, IEC 61508, EN 50128.
5. Unnecessary duplicated code blocks are identified and removed, therefore optimizing your testing effort and maintenance effort over time.
6. Testing is both comprehensive and efficient by identifying untested pieces of code. "

(...)

"The proven verification capabilities of IBM Rational Logiscope help you optimize expensive development resources to reliably deliver on-time, on-budget, and to specification.

IBM Rational Logiscope currently supports four programming languages: C, C++, Java, and Ada. It is available on Windows, UNIX, and Linux platforms and includes four different products:

• IBM Rational Logiscope RuleChecker, for code rule checking
• IBM Rational Logiscope QualityChecker, for code quality metrics
• IBM Rational Logiscope Code Reducer, for finding code similarities
• IBM Rational Logiscope TestChecker, for dynamic test coverage analysis

IBM Rational Logiscope RuleChecker V6.6 introduces support for MISRA C++ code rules checking, allowing organization to comply with this industry-standard set of rules. IBM Rational Logiscope RuleChecker now allows verifying MISRA code rules on code generated by IBM Rational Rhapsody."

Git Pull Requests vs. Formal Code Reviews?

Is a pull request equivalent to a (formal Fagan) Code Review? 

The Short Story

Well... Maybe yes if you do some additional work over BB/Git. 

Out of the box: NO.

First, remember what is a pull request (and what it is good for):
https://help.github.com/articles/about-pull-requests/
https://help.github.com/articles/creating-a-pull-request/
https://help.github.com/articles/requesting-a-pull-request-review/

Why aren't they equivalent?
Because formal review procedures typically require the creation of review records (CRRs are separate - potentially deliverable - documents that identify the scope of the review, the reviewers, the subject under review and all the issues identified) and the collection of metrics that might be checked against (code review) performance baselines in order to evaluate the quality of the review being performed and feed the continuous improvement process. 

The Long Story

If you do not generate CRRs you might get into re-certification issues (difficulties showing compliance, verifiability and making the records auditable) or contractual issues (if the customer needs and/or demands you evidence of code reviews being performed).
So it is a good mechanism to improve code quality but they could not replace totally a formal [Fagan] code review unless you generate (manually or automatically with some bespoke scripting) CRRs.

INTERNAL: Projects should use a lot pull requests (since they also contribute to code quality improvements even though efficacy and efficiency are hard to attest and prove), and code reviews at Crucible (the official tool for CR) when compliance is needed internally (with the Verification Process: Large projects, Large Teams, budgets >= 125 KEUR) and/or when review records are needed for the customer or the standards of the target market.

Kudos to D. Almeida for the distinction of the 2 (apparently) similar and redundant mechanisms.

Review Procedure: Document reviews for dummies?

You do review documents before delivering/publishing do you?
How do you review documents (hands-on)?
And what do you do when the documents you receive are not in the more commonly editable formats? Or when you do not have a license of Microsoft Office / Microsoft Office 365?
So many questions, so many answers...

Note: Some of the considerations below assume you are using an Office Suite (that supports tracked changes and peer review comments).

Review roles

There should be a moderator for the review (the person that should make sure everyone reviews things in time and that makes sure a reviewed artifact comes out of the peer review activity). This could be the author, or not. All other involved are peer reviewers.

Note: Some process definitions can differentiate the moderator from the author roles. For larger teams, it could make sense. For smaller teams and / or more informal organizations, the author could work as moderator.

Review Types

There are several types of (document peer) reviews. Think: Commentary, Walk-through, Full-reading (run from those ones!). We are talking mainly of the Commentary ones here.

How do you peer review (The Process)? 

Ideally you (as a moderator for the review) should ask for peer reviewers to edit inline trivial errors (such as typos); and comment the document with whatever needs commenting (a comment is a sentence regarding the selected text the comment is about). Comments should be done "near" the paragraph / section they are related to.
The document could be reviewed simultaneously but it will be better (e.g. avoiding duplicated comments) to be circulated between all review members.
Circulation could be made by e-mail, or using the DMS and / or VCS: I will make my review and I will commit the version with my comments to the VCS (while warning the next person - or the whole review team - that the comment is free for the next reviewer).

This really depends on what your review process / procedure states in your QMS.

If the review team is not fully inside the subject of the the document, and/or the objective of the peer review, it might be a good idea for you to do a presentation of the document being reviewed (a meeting where the document and the objectives is presented; eventually the check-lists to use as input for the review could also be presented; and the schedules for the review are emphasized: "Do this for tomorrow, or else..."). In this meeting you could also explain how the review will be done (in sequence, all at the same time, using what tools for commenting, ...).

In the end of the rework (rework is made based on the peer review comments that are approved for implementation) the moderator could have the power to ask for a re-review. Mainly it will be a good idea if the rework that has been done was profound and if you feel that a new review (delta, or full) is needed to ensure the final document quality. Look at the review process / procedure in your company for rules on re-reviews.

Sometimes it will be mandatory for the review organizer to extract (or make a tool extract) the review metrics. That could include, #of comments, how many of them were acknowledged (and implemented), how many were dismissed, etc. A metrics repository could be fed with this (important performance) information. Ask about that part also (company dependent).

With what tools (The Supporting Tools)? 

- If you are producing the document internally, deliver it internally for peer review in an editable format. If everyone has the app to edit it (and that app supports comments).
- If someone does not have a license of Microsoft Office, try to see if free Office Suites are suitable for your document (some Office Suites will "damage" more complex documents; think: Open Office, Libre Office, ...). If so, recommend installation of those.
- "Google docs" allows you opening and commenting (MS Office) documents. So it could be an option. Just test it with the concrete document you need to review.

If you only have a PDF and you want to peer review it you could:
- Try to create an editable document from the PDF (several utilities can be found - google is your friend, but do test the conversion since more complex docs could not be well extracted/converted).
- Try to comment right away the PDF: https://www.adobe.com/content/dam/Adobe/en/feature-details/acrobatpro/pdfs/adding-comments-to-a-pdf-document.pdf

Merging Comments (If possible, No)? 

In the end, if you do a sequential comment workflow (which is recommended and will dispense you from having to merge all peer reviewers comments into a single document) the document owner (the one responsible to process and close all comments provided) will receive a single file, that went through all peer reviewers to process.

If you have several documents with comments from several reviewers, do not dispair. Remember that MS Word has that wonderful feature to merge 2 versions of the same document (try to save one above the other and MS Word will offer to Merge contents). A tracked changed version (with all comments merged also) can be produced in this way.

Easy ain't it? :)

Note: If you opt to use an Office Suite like google docs (of Office365) that allow concurrent edits by several users at the same time (without frequent unsolvable merge conflicts that tear your hair apart), the merge part is not needed, of course.

Recap 

Read the guidelines to peer review artifacts in your QMS. Know if there are check lists associated to check against, during the review. Know how to edit inline and comment a paragraph, Know how to circulate the document between the team. And be a good boy: do review technically and formally the stuff. Do not just point formatting and English issues (but do report those also).

Further Reading (The Process stuff): For further info, look for your company's SUP03 - Verification Process and the Review Procedure documents (or equivalent), that shall detail the above considerations. Mine's are here: https://goo.gl/4EKKec (INTERNAL resource).


History:
@2017-04-26: Added INTERNAL QMS links; added Google Docs note; updated tags.

Code Reviews and the "If it ain't broke, don't fix it" principle

"If it ain't broke, don't fix it." is credited to Bert Lance as the person who popularized it, when he was quoted saying it in the May 1977 issue of the magazine Nation's Business.The expression became widespread, and William Safire wrote that it "has become a source of inspiration to anti-activists." - Wikipedia

Sometimes this principle will be put in place while performing Code Reviews (CR is a verification measure that intends to spot software defects by reading the software source code, as early as possible in the software life cycle). This only means that the main reason you are reviewing the code is to spot defects, so optimizations, formatting issues are out of scope (even if they bother you, don't engage into unnecessary discussions with the author).

Unless, of course, they are part of the written coding conventions for the project (some projects will inherit whatever the company or the customer have). This means that indenting code at 2 spaces instead of 4 could be a defect if there is a coding convention for this team that requires this specific indentation.

Also sometimes, as input to a code review a check list (of different sizes ;) could be handed to you. And those check lists could cover more that spotting defects.

So this principle applies in principle for code reviews unless there is a good reason to break it (Software coding conventions, check lists that are input to each code review).

Got it?

TOOLS: Source Monitor (Static Analysis - Multi-language)

Static analysis refers to analysis of the code statically (without running it).
There are several tools embedded in modern IDEs (as plugins or even natively).
There are also some standalone multi-language tools.
A simple (and free) example of a tool like this is the multi-language tool named Source Monitor:

• http://www.campwoodsw.com/sourcemonitor.html

Quoting:
"The freeware program SourceMonitor lets you see inside your software source code to find out how much code you have and to identify the relative complexity of your modules. For example, you can use SourceMonitor to identify the code that is most likely to contain defects and thus warrants formal review. SourceMonitor, written in C++, runs through your code at high speed, typically at least 10,000 lines of code per second. SourceMonitor provides the following:

• Collects metrics in a fast, single pass through source files.
• Measures metrics for source code written in C++, C, C#, VB.NET, Java, Delphi, Visual Basic (VB6) or HTML.
• Includes method and function level metrics for C++, C, C#, VB.NET, Java, and Delphi.
• Offers Modified Complexity metric option.
• Saves metrics in checkpoints for comparison during software development projects.
• Displays and prints metrics in tables and charts, including Kiviat diagrams.
• Operates within a standard Windows GUI or inside your scripts using XML command files.
• Exports metrics to XML or CSV (comma-separated-value) files for further processing with other tools."

What do you do static analysis for? 
Some reasons include:
- For quickly gaining insight on some new code (to you) when entering a project
- For spotting difficult parts of the code (in terms of complexity for example), spotting refactoring candidates
- For quickly analysing some quality attributes of the code being produced by the team (as a Technical Manager or mini-team leader, for instance % of comments when compared to LOC)
- For presenting reports to the customer on specific quality attributes of the code (Kiviat Charts with KPIs and an optimal region where we would like or are obliged to have the code).

History: Added details, quote 2017-11; 2017-12-04: Minor rephrases;