Closed Jquinny closed 2 months ago
No problems need attention.
Have any feedback or feature suggestions? Share it here.
Descriptor | Linter | Files | Fixed | Errors | Elapsed time |
---|---|---|---|---|---|
✅ PYTHON | mypy | 1 | 0 | 1.21s | |
✅ PYTHON | ruff | 1 | 0 | 0.01s |
See detailed report in MegaLinter reports
_Set VALIDATE_ALL_CODEBASE: true
in mega-linter.yml to validate all sources, not only the diff_
Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it relates to an open issue, be sure to link to that issue. Ensure that you add a label to the PR describing the type of change (if the issue does not have one already for whatever reason).
Added cpp and python linting in vscode using mypy/flake8/black/isort for python (also added auto docstring for convenience) and clang-tidy/format using clangd language server for cpp. The idea is to have linter hints and the ability to autoformat and fix errors using the editor, but not have anything strictly enforced until PR time. In addition, workflow jobs have been created for linter checks that will mirror the tooling/checks used by vscode. These will ensure code being merged to main follows best practices.
work still needs to be done in setting up the job for linting python code, as well as for ensuring the CI jobs actually work for the jetson, as that is ultimately where the code will be running. I will be adding documentation for using all the linting tools and for understanding the output of the actions (and steps to take if they fail when making a pr). This will ensure new members have the resources required for fully utilizing these tools and understanding why we have them.
closes #63
Checklist
Put an
x
in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...
I ran into some issues using vscode's c/cpp extension for linting. It uses clang-tidy and clang-format, but it has a separate language server (not clangd). The linting would work the first time you open a file, but then any changes wouldn't be registered by the language server, it would just stall indefinitely. I had to switch to using the clangd extension as the cpp language server, and just using the c/cpp extension as a debugger (and since the ROS extension requires it).
The checks for the linters might be unnecessarily restrictive right now, but that gives us the option to just remove specific checks if they are too annoying or are unproductive for our codebase.