Take-Home Messages from Adding Code Quality Measures to GRASS GIS
Formal Metadata
| Title | Take-Home Messages from Adding Code Quality Measures to GRASS GIS |
|
| Title of Series | |
| Number of Parts | 351 |
| Author | |
| License | You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. |
| Identifiers | |
| Publisher | |
| Release Date | |
| Language | |
| Production Year | 2022 |
Content Metadata
| Subject Area | |
| Genre | |
| Abstract | The message is not surprising: You should quality check your code, too, even if you are writing a small script for your own needs! However, maybe you wondered if all the warning messages are relevant to you or got discouraged after getting a flood of messages from tools like Pylint. Perhaps you were even annoyed by it. This talk will help you get motivated and get started and how to automate that with continuous integration tools such as GitHub Actions.
In this talk, I will share my experience with adding various code and non-code checks to GRASS GIS which is primarily written in C, C++, and Python. Checking a mixed code base with over 30 years of development is not easy, but not impossible. The talk will cover code quality measures in GRASS GIS such as tests, Pylint, Black, GCC, CodeQL, and Super-Linter and how this compares to my experience with new and small organizational repositories. |
|
| Keywords | |