|
1 | 1 | # xSDK Code Quality Tools |
2 | 2 |
|
3 | | -The goal of this project is to facilitate the use of both general-purpose and custom code analysis tools with the |
4 | | -goal of improving the quality of software developed in the DOE xSDK ECP project, as well as more broadly within |
5 | | -the high-performance applications community. |
| 3 | +The goal of this project is to facilitate the use of both general-purpose and custom code analysis tools with the goal of improving the quality of software developed in the DOE xSDK ECP project, as well as more broadly within the high-performance applications community. |
6 | 4 |
|
7 | | -## General-purpose tools |
| 5 | +## 1. General-purpose tools |
8 | 6 |
|
9 | 7 | Many commercial and open-source projects provide various code analysis capabilities that can be used to |
10 | 8 | detect various problems, ranging from style to correctness and performance. |
11 | 9 |
|
12 | | -Here we focus on widely available open-source tools which can be deployed easily in HPC software projects without |
13 | | -requiring significant modifications to existing development processes. |
| 10 | +Here we focus on widely available open-source tools which can be deployed easily in HPC software projects without requiring significant modifications to existing development processes. |
14 | 11 |
|
15 | | -### Clang analyzer |
| 12 | +### 1.1 Clang analyzer |
16 | 13 |
|
17 | 14 | Perhaps the easiest code checker to integrate is the [Clang analyzer](https://clang-analyzer.llvm.org). In particular, |
18 | 15 | the `scan-build` command allows non-intrusive integration of |
19 | 16 | code checks into existing builds (including parallel builds). The `scan-build` [documentation](https://clang-analyzer.llvm.org/scan-build.html) |
20 | 17 | provides a great starting point for developers wishing to integrate code quality checks into their workflows. |
21 | 18 |
|
22 | | -### Clang-tidy |
| 19 | +### 1.2 Clang-tidy |
23 | 20 |
|
24 | 21 | The `clang-tidy` tool provides an extensible framework for diagnosing and |
25 | 22 | fixing a variety of typical programming errors. The [documentation](https://clang.llvm.org/extra/clang-tidy/) |
26 | 23 | includes several examples of command-line invocation, as well as a list of all available checkers. |
27 | 24 |
|
28 | | -## Custom code analysis tools |
| 25 | +## 2. Custom code analysis tools |
29 | 26 |
|
30 | | -While general tools provide valuable functionality in detecting a variety of problems, most projects also have |
31 | | -unique requirements in terms of coding conventions. In our tools, we aim to enable such custom analyses through |
32 | | -[static](https://github.com/HPCL/code-analysis/tree/main/src/static) and [dynamic](https://github.com/HPCL/code-analysis/tree/main/src/dynamic) |
33 | | -code analysis tools based on the open-source LLVM compiler framework. |
| 27 | +While general tools provide valuable functionality in detecting a variety of problems, most projects also have unique requirements in terms of coding conventions. In our tools, we aim to enable such custom analyses through [static](https://github.com/HPCL/code-analysis/tree/main/src/static) and [dynamic](https://github.com/HPCL/code-analysis/tree/main/src/dynamic) code analysis tools based on the open-source LLVM compiler framework. |
34 | 28 |
|
35 | 29 | Our static analysis approach extends clang-tidy, while our dynamic approach relies on the Python bindings |
36 | | -of the LibClang interfaces to the abstract syntax tree program representation. |
| 30 | +of the llibClang interfaces to the abstract syntax tree (AST) program representation. |
| 31 | + |
| 32 | +Well documented projects, such as [PETSc](https://petsc.org/release/developers/style/), have a set of coding rules that are included as part of the developer documentation or contributor style guide. In addition to lowering the learning curve related to the project's source code organization for new developers, having style rules helps clarify semantic aspects of the code in question. For example, in projects written in languages without mechanisms for controlling encapsulation and polymorphism, such as C, coding conventions are the only way in which software can be designed using object-oriented principles. As a consequence, violating these styles and conventions affects not only code maintainability, but could result in serious bugs. Even languages that provide support for data protection and other design tools, more domain-specific design rules almost inevitably can improve the overall code organization and enable a wider range of contributions without sacrificing quality or maintainability. |
| 33 | + |
| 34 | +To ease the burden of manually verifying that new codes obey the project's style and structure requirements, we have implemented a number of analyses for PETSc developer rules, which can be used as starting points for developing future custom rules for other C projects. We will also add examples for Fortran and C projects in the near future in the same repositories. |
| 35 | + |
| 36 | +## 3. Getting Started |
| 37 | + |
| 38 | +To clone this repository and all its submodules (recommended), use the following command: |
| 39 | + |
| 40 | +``` |
| 41 | +git clone --recurse-submodules --remote-submodules https://github.com/xsdk-project/xsdk-code-quality.git |
| 42 | +``` |
| 43 | + |
| 44 | +To update a previously cloned copy, including all its submodules, do this in the `xsdk-code-quality` top-level directory: |
| 45 | + |
| 46 | +``` |
| 47 | +git pull --recurse-submodules |
| 48 | +``` |
| 49 | + |
| 50 | +To obtain clone a specific release, clone the corresponding tag, e.g., for version 1.0.0: |
| 51 | + |
| 52 | +``` |
| 53 | +git clone -b v1.0.0 --depth 1 --recurse-submodules --remote-submodules https://github.com/xsdk-project/xsdk-code-quality.git |
| 54 | +``` |
| 55 | + |
| 56 | +All available versions: https://github.com/xsdk-project/xsdk-code-quality/tags |
| 57 | + |
| 58 | +(Containerized distribution coming soon!) |
0 commit comments