Coding Standards

Syntax

• Everyone uses eslint as a linter to assure common syntax practices and to improve overall code robustness
• Favor top of page comments over inline comments
• Use Prettier to fromat code automatically and keep the style consistent between all developers

Function and Variable Naming

• Defer to programming language default. E.g. Python uses snake_case, while TypeScript uses CamelCase

API naming conventions

• //; e.g., /delete/remove_user
• We may use convex.dev as our backend, so this may not be entirely applicable.

Data Formats

• Core data layer abstracted by https://www.convex.dev/ - ensures structured data both on the backend and frontend without time-consuming schema synchronization.
• For external APIs, type-safe JSON

Pull Requests

Branching

Any new branch should be titled as: /-workarea. For example, fix/jay-pose-estimation

Opening a PR

• Create a PR template that is auto-generated upon opening PR. In this template we can follow a format similar to as so:

# SUMMARY
<!-- Comment on what this PR does at a high level -->

# CHANGED

# ADDED

# DELETED

# TESTING

# ISSUE
<!-- Link to relevant GitHub issue -->

• PRs must be linked to the issue they are addressing!

Closing a PR:

• The original opener of the PR should ALSO close it (the reviewer should not close and merge someone else’s PR for them
• Utilize the comments in the PR to refer to specific changes and resolve them individually
• When merging to main, always squash the commits (unless there’s a reason why stepping through each commit in a rebase might be relevant to the next person merging in your code).

Rules to live by for PRs

• No PR should be over 1.2k lines of non-autogenerated code
• Indicate what files need to be reviewed vs autogenerated *Autogenerates is different to ai-generated!! (e.g. yarn.lock)

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 24 hours.