Skip to content

profile

Directory actions

More options

Directory actions

More options

Latest commit

 

History

History

profile

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
README.md
README.md
 
 
python_style_guide.md
python_style_guide.md
 
 

README.md

Software Development Policies

Python

  • All Python projects shall use the psf "black" code formatter or the ruff linter and the mypy type checker.
    • All linting and type checking shall be performed in pre-commit hooks and GitHub Actions.
    • Badges shall be added to the project's README file for linting and type checking.
  • All Python projects shall use pre-commit hooks for linting, type checking, and formatting.
    • Formatting shall be done in pre-commit hooks so that linting and type checking are done on formatted code and the git history is clean.
  • All Python projects shall have unittests that execute automatically on pull requests to pre-production and main branches
  • All Python projects shall follow this style guide.
  • Follow the Zen of Python.
  • All Python classes and functions shall have type hints and doc strings, no matter how trivial (e.g. a function doesn't return anything: def f(...) -> None:)

API

  • All endpoints shall use kebab-case.
  • All fields in responses shall use snake_case.

Web Development

  • Web applications shall be built using React.
  • Web applications should be built using a React metaframework; Refine.dev is preferred.
  • Web applications shall use MaterialUI or PrimeReact as a UI component library.
  • Web applications shall be bundled using Vite.

Database

  • PostgreSQL shall be used for all projects.
    • Extensions, such as PostGIS and TimescaleDB, may be used in conjunction with PostgreSQL.
  • Databases shall be maintained such that they are never using an EOL version.

Git & Collaboration

  • Git commits shall follow Conventional Commits standards.
  • All default branches shall be named main.
  • All base staging branches shall be named staging.
    • All users shall base their development branches off of staging.
    • When ready, a pull request shall be opened from a user's development branch into staging. After mergeing with staging, all project participants shall pull the latest staging updates to their local environments, merge those changes to their development branches, and resolve merge conflicts.
  • All tests must pass before a development branch can be merged with staging.
  • All merge conflicts must be resolved before a development branch can be merged with staging.