6.- Maintainability

Maintainability refers to the ease with which a product can be maintained in order to isolate and correct defects or their cause, repair or replace faulty or worn-out components without having to replace still working parts, prevent unexpected breakdowns, maximize a product’s useful life, maximize efficiency, reliability, and safety, meet new requirements, make future maintenance easier, or cope with a changing environment.

Depending on the used programming language, maintainability is also related to the adherence to the official language programming standards. Examples:

• For C:
  • C18: The international standard which defines the C programming language is officially known as ISO/IEC 9899:2018 – Information technology – Programming languages – C, and it is available from ISO, IEC, and ANSI. You can obtain something very close to the standard for free because of the working drafts available, the closest is N2176. It introduces no new language features, only technical corrections and clarifications to defects in C11.
  • C11: The former international standard which defined the C programming language, ISO/IEC 9899:2011, is available from ISO. You can obtain something very close to the standard for free because of the working drafts available, the closest is N1570.
  • C99: An older standard ISO/IEC 9899:1999 is unavailable from official sources, due to the ISO adoption of C11. The closest free working draft is N1256.
• For C++:
  • Draft C++23: Check the C++ standard draft sources at GitHub.
  • C++20: The current ISO C++ standard is officially known as ISO International Standard ISO/IEC 14882:2020(E) – Programming Languages – C++. You can get it from ISO, IEC, or ANSI. The closest free working document available is N4868.
  • C++17: The former ISO C++ standard was officially known as ISO International Standard ISO/IEC 14882:2017 – Programming languages – C++. You can get it from ISO, IEC, or ANSI. The closest free working document available is N4659.
  • C++14: An older ISO C++ standard was officially known as ISO International Standard ISO/IEC 14882:2014 – Programming languages – C++. You can get it from ISO, or ANSI. The closest free working document available is N4296.
  • C++11: An older ISO C++ standard was ISO/IEC 14882:2011. You can get it from ISO. The closest free working document available is N3337.

In other programming languages, this could refer to the minimum (oldest) / maximum (most recent) working version(s) of the corresponding compiler or interpreter. Examples:

• Python interpreter above 2.7 and/or 3.4+.
• Matlab version above Release R2017a.
• The Java Language Specification.

Ideally, a given software should be executable in a broad range of platforms, even in those yet-to-be-released at the time the software was released. However, this is not straightforward. For instance, Ubuntu (one of the most popular GNU/Linux distributions) releases a new version of the OS every 6 months. Other distributions such as Arch Linux and Gentoo Linux are rolling release systems, making packages available to the distribution a short time (days or weeks) after they are released upstream. Libraries’ API change over time and, as a consequence, software environments are constantly mutating and software building or execution is likely to fail due to the API-breaking features introduced in different OS versions. This also holds in the case of using scripting languages (such as Matlab/Octave or Python), where this step is recommended in order to check whether the code runs as expected in the different versions of the language interpreter and associated packages shipped with different OS.

This issue can be addressed with Continuous Integration, a concept firstly introduced by Booch¹ which consists of automating the build and testing of code every time a researcher commits changes to the version control system²\(^{,}\)³\(^{,}\)⁴. Continuous Integration encourages developers to share their code and unit tests by merging their changes into a shared version control repository after every small task completion. Committing code triggers an automated build system to grab the latest code from the shared repository and to build, test, and validate the obtained numerical results. This helps to identify integration and backward/forward compatibility problems as soon as the offending instruction is committed or a new OS version appears, so they are easier to fix, and ensures that code performs as expected in different environments.

In addition to the adherence to programming language standards and the set up of a Continuous Integration system, maintainability in open source projects is also related to the consistent observance of well-defined code formatting guidelines, which help other developers to read and understand the source code without the hassle of changing formatting styles along pieces written by different authors. Automated tools for code formatting such as clang-format are highly recommended.

Indicators of Maintainability

It follows a list of possible maintainability indicators for a software-defined GNSS receiver:

• Time to Fix Defects.
• Source code under a version control system.
• Well–established programming language.
• Availability of a Continuous Integration system.
• Availability of an issue tracking system.
• Availability of “debugging modes” and tools.
• Availability of static and dynamic code analysis tools.
• Definition of a source tree structure.
• Automated documentation system.
• Availability and observance of a coding style guide.
  • Availability of automated code formatting tools and corresponding configuration (e.g., availability of a .clang-format file).
• Availability of required and optional software dependencies (type of license, pricing, maintenance / development status).

References