add formatting and linting

[dragonejt]

This PR adds linting using Pylint and formatting using Black, and adds a GitHub Actions workflow to check linting and formatting on each new push or PR. This is functionally optional, but sets a guideline for formatting so there aren't any formatting conflicts or code smells.

Changes

• Add black. Run the black formatter with black ..
• Add pylint. Run pylint python linter with pylint <module>.
• Format code using black
• Add GitHub Actions workflow that checks linting and formatting on each new push or PR

Testing

• Unit Tests are succeeding
• Linting and Formatting checking is working (Pylint is complaining though due to code smells we can fix later)

[asgibson]

This PR is appreciated and the concept is good.

Out of curiosity, do you have rationale behind the choices of applications? Particularly interested in why you chose Black and Pylint versus any other available options.

[asgibson]

Does it make sense to add these as dependencies for all usage? Perhaps we can have a specific environment file just for CI runs.

[dragonejt]

This is true, conda doesn't natively support dev dependencies so I didn't separate them, but I can add something like a environment_dev.yml

[asgibson]

Yes, please do so.

[dragonejt]

This PR is appreciated and the concept is good.

Out of curiosity, do you have rationale behind the choices of applications? Particularly interested in why you chose Black and Pylint versus any other available options.

I chose Black and Pylint because of their popularity, support, and ruleset. Black and Pylint are probably the more popular and more supported code formatters and linters, and this is helpful when it comes to IDE integrations with VSCode and PyCharm as you can see linter violations directly in your IDE based on the linter rules you have set/unset. Black also contains a superset of the normal PEP 8 python code format standard. There is also just how mature they are, these are relatively mature tools compared to newcomers like Ruff, and that is useful because we don't want our code formatters and linters to break or have breaking changes.

This decision is purely opinion-based, and it is relatively easy to switch to a different code formatter or linter if we want to.

[asgibson]

Thank you for the explanation, it is much appreciated. Once the environment_dev.yml is added and used in CI, I will approve this PR.