Team Coding Standards

Team Coding Standards

**Last Updated: **2/20/24

Syntax

• We will use flake8 and Black default style checkers
• As far as is reasonable, we should include sub function header comments explaining what each function expected behavior is
• Tab indentation only. No space indentation.

Function and Variable Naming

We will use the given language’s standard naming conventions. I.e C++ will use camelCase and Python will use snake_case. As we expand to using more languages, we can quickly get a consensus on what is considered that language’s standard, which should take no time at all.

API naming conventions

/<action type>/<specific action>; e.g., /delete/remove_user

Data Formats

Data will be passed in JSON format whenever possible according to the following conventions:

• Keys for data are concise, yet descriptive
• Maintain consistency in data structures and fields across endpoints (GET and POST)
• Use nested objects for hierarchical data
• Encode all data to prevent corruption when in flight

Pull Requests

Branching

• Any branch should be immediately recognizable as being under ownership of a specific user. There is no need to necessarily use one's own username, but best judgment can be used.

Commits

• The commit description should make it clear to a reviewer what the commit accomplishes.
• Incremental commits are encouraged as opposed to one giant commit; however if your commit is large or is particularly complex, your commit description should call that out.

PR and PR Reviews

• For any work to be merged into main it must go in as a pull request (PR) and must be reviewed by at least one other member of the team. Please take time in the comments associated with your pull request to detail the changes and describe how a reviewer can test for expected functionality.
• Anybody on the team should be free to tag anyone else as a reviewer.
• If you have been tagged as a reviewer, you will make every effort to complete a review within 48 hours.