There are a variety of coding guidelines at EPFL. Some focus on a lab’s preferred language and their specific tools, some are more on project handling and general git usage. Most are a mix of the above.
Sadly, theses guidelines aren’t scrupulously followed, aren’t usually automatically checked and some are even unknown to the people in the lab. The aim of this article is to raise awareness of theses documents. First, by having a list of the existing ones, then to work with the labs to improve their usage and usefulness. Hopefully, by referencing theses rules regularly and by providing easy ways to implement it, general code quality will improve. It will be linked with the Maturity Evaluation.
Here goes the list of currently known documents and some comments to quickly grasp each. If you know some more, please contact Valérian Rousset.
- LDS
- overall very good guidelines, from readability to content
- coding guidelines: formatting, testing, documentation
- project handling guidelines: how to handle a repository and cooperation in a team
- git/github: branch handling,
CODEOWNERSto auto assign review, do small commits/PRs - golang: language specific tips & good usage, good links to libraries
- DEDIS
- quite small with code examples, very opiniated
- tests: naming, helpers at the end, test first “happy path” then errors
- errors: be verbose
- golang/comments: syntax for implementation, 80chars
- golang/misc: use empty lines, constructor starts with
New, do not use named return
- SPRING
- quite small with some libraries & code examples, into a larger “student onboarding” document
- python/doc: state input & output with types
- python/code: format using
black - python/tests: unit tests (one per function), separated by module, use
pytest
- MLO
- python/code: format with
blake, use Makefile with checker - git/github: use semantic versioning branch (
v2), PR must pass tests & lint, maintainer approved
- python/code: format with
- LSIR
- git/github: use
git-flow - python/code: format with
flake8
- git/github: use