TST: adding a linter

[aburrell]

New Feature

Name: N/A

function: main.yml

bin/lib: /.github/workflows

Description & User Interface

Expand the CI testing to include a linter.

One possible linter is: https://megalinter.io/latest/. It has an Action for GitHub Actions, and can be configured in different ways: https://github.com/oxsecurity/megalinter/blob/main/docs/install-assisted.md

We could also use cpplint. Here's a version that's more actively maintained: https://github.com/cpplint/

RST Checklist

• Does the feature fit within RST's scope?
• Is this a major or minor change?
  • Major: initializing this does not affect existing functionality, but will impact the way code is written by requiring a style.
  • Minor (e.g. addition of a new self-contained library)
• Do you need help developing it? No help needed to add the test, but if we require this across the codebase help will be required.
• Have you created a (github project)[https://github.com/SuperDARN/rst/projects] to reflect the process of developing it? (optional)
• Can the code be released under the GPL v3.0 license?
• Does the source code include copyright and authorship information? (can be added later at the pull request stage)

Development help

RST does not have a dedicated team for full feature development. However, the community may be able to assist you with development.

If you need help please indicate what expertise you are looking for:

• developer help with design and integration of code
• scientific help to ensure that the new feature produces the expected results
• project management to help organize the steps involved in adding the new feature to RST
• other: potentially, help updating style across the codebase.

Note: all code will be tested/reviewed before being merged into the RST codebase.

Timeline

1. Discussion on linting in DAWG.
2. If yes, start by linting just new code or the entire codebase?
3. Add linter either in main.yml or a separate yaml (I am thinking a separate yaml is the way forward).
4. Add rules/standards for merging .

Extra Notes

Maintaining a large codebase with multiple developers who enter and leave the project is easier when there are style guidelines that can be checked by a machine. This lowers the barrier for entry with new users: https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/

[ksterne]

@aburrell, I like the idea of doing this as I often find it tricky to get into some parts of the code that have an different style that I'm expecting. The only reference I have with this was when we put in place PEP8 style rules during the days of davitpy. I remember it being a fairly daunting undertaking to get all of the files resolved...and I think davitpy is smaller than rst. So I think I'd be in favor of implementing it on any new or modified code.

I wanted to ask here before our next meeting, is this something that we can easily do or once we add in the yml file, will the whole codebase be checked?

[aburrell]

@ksterne I'm not sure, I've not implemented such checks on C code before. I hope we'll be able to do both. That would mean we could put the new code check in the main yaml and the whole codebase check in a separate yaml. That would allow folks with time, students diving into the codebase, etc something targeted to do to improve RST.