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"

CI: Continuous integration in science projects

About CI in scientific (development) projects:
http://www.nature.com/news/collaborative-software-development-made-easy-1.22729

Quoting:
"In 2015, in an effort to save time and resources, the team took inspiration from the technology industry, automating their testing using a process called 'continuous integration'.

In continuous integration, changes to software code automatically trigger repetitive tasks, such as error-checking. Fundamentally, the process simplifies a task that diligent coders already perform. Programmers usually write lists of tests that they will run periodically to ensure that their code still works, just as Neubert's team do.

But a busy team might forget or lack the time to run them, allowing errors to creep in. Continuous integration automates that process so those checks run whenever a change is proposed, saving team members the time they would spend hunting down an error. A team running genomic analyses could spend more time at the bench, while a group developing climate-prediction software could better refine its models. That said, the resulting peace of mind is only as good as the tests themselves: a poorly designed test can still allow mistakes to pass undetected.

The process is common in the commercial and open-source sectors. A study presented at the 2016 IEEE/ACM International Conference on Automated Software Engineering in Singapore found that about 40% of the 34,544 most-popular open-source projects hosted on the coding collaboration site GitHub used continuous integration in some form."

DIGEST: SW Construction - Further Reading

Additional Resources for SW Construction:

While building your software (aligned with the gathered requirements - SRS - and the software design that your high-level architecture defines - SAS) several additional topics are relevant. For instance: Coding standards to comply with (if any); comments to create and % of comments and eventual traceability to requirements IDs / component ID there left; static analysis to perform (and extracted KPIs to comply with - if any); continuous integration server and tasks to use; verification measures such as unit tests, code reviews. For more generic information on these topics see here.
   
For further detailed information please see the following links (some are INTERNAL).

Static Analysis: 

1. http://silvaonsoftware.blogspot.pt/2016/05/tools-source-monitor-static-analysis.html
2. http://silvaonsoftware.blogspot.pt/2016/05/tools-static-analysis-tools-listing.html
3. http://silvaonsoftware.blogspot.pt/2016/10/sw-construction-static-analysis-tools.html

Code Reviews: 

1. The QMS context (INTERNAL): Review Procedure here; Crucible Tool GBK here; CheckStyle (Java) tool GBK here.
2. Code Reviews example - Crucible (Plugin to JIRA; INTERNAL): https://crucible.critical.pt/cru/ATG-5#CFR-11408

Continuous Integration (CI):

1. About CI, a list of several servers available can be seen here: https://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software
2. Example - Jenkins (INTERNAL): http://jenkins.critical.pt/computer/(master)/ (INTERNAL; Teamcity could also be in use for some projects).

Unit Testing: 

1. Think "developer tests" (and see Module 9 for now; again, INTERNAL)

Further reading - Coding Standards: 

Each company might have internally defined coding standards. Or it could be using external standards (e.g. HP, NASA, ESA, etc.). Google for "C Coding Standard" and see what it is meant by coding standards here: For instance this is 1994 NASA-SEL's style guide for C (PDF).

Further reading - BOOKS: 

There are lots of books on SW Engineering that focus on best practices for coding activities, with the objective of writing clearer code, easier to understand and maintain, easier to reuse, etc. 

Two must read examples might include: 

• Clean Code - Robert C. Martin, 
• Code Complete 2 - Steve McConnell

Many more books have full chapters on writing "good" code. 

Again, "Google" and/or "Amazon" for it.

Happy readings!