Team Coding Standards

Team Coding Standards

Last Updated: March 20, 2024

Syntax

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

Function and Variable Naming

We will use the given language’s standard naming conventions. For Javascript, we will use camelCase, and for Python, we 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.

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 use one's own username necessarily, but best judgment can be used.

Commits

• The commit description should clarify 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

• Any work to be merged into main must be submitted as a pull request (PR) and 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 try to complete a review within 48 hours.

Notes on Deployment

We are currently deploying our application on an AWS EC2 instance. There are two workflows for deployment depending on the frontend or the backend.

Frontend

We currently have a Bash script that builds our React application, copies it over to the root nginx folder, and then restarts nginx. This can all be run using:

cd frontend
sudo sh deploy.sh

Backend

Our backend can just be started by running FastAPI. This works by first activating a venv with all the appropriate packages installed, and then running:

cd backend
uvicorn api:app --reload