Step 5: Linting and formatting

[annie444]

This PR adds common linting and formatting rules to the code base using ruff.

I configured ruff with the defaults for code quality as specified in the documentation for ruff. To ensure standard code formatting, you can run ruff format, which will format all files (including the jupyter notebooks) following the PEP standards and the configuration stated in the [tool.ruff] sections of the pyproject.toml. To ensure standard linting and to stay up to date with general python code standards, you can also run ruff check to lint all files. This will output all linting errors, warnings, and suggestions. You may also use ruff check --fix to automatically fix the linting rules that have auto-corrections. Note that ruff format nor ruff check --fix will rewrite any logic. These commands will only modify the syntax of the code.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[jaladh-singhal]

It's a good coding practice to use code formatters/linters. But firefly-client didn't get the chance to implement it because of limited resources. Ruff is top choice (I've used it in other projects) but firefly team should decide it first before implementing it.

[jaladh-singhal]

Did you intend to introduce types in this PR? I thought it was only for code-formatting/linting

[annie444]

There's a lint included in the ruff default lints that complains about class variables that mutate not being explicitly typed as class variables, so that meta type was added. However, with it being a meta type and not a static type, it has no effect on the code.

[annie444]

It's a good coding practice to use code formatters/linters. But firefly-client didn't get the chance to implement it because of limited resources. Ruff is top choice (I've used it in other projects) but firefly team should decide it first before implementing it.

I would suggest looking at linting rules. The explicit linter that's used doesn't matter as much as the rules. For instance, ruff simply combines all of the linting and formatting rules from all the different python linters and formatters into one place (plus a few extra lints). For instance, I'm currently using the following linting rules:

• E4 - pycodestyle import sorting rules
• E7 - pycodestyle statement formatting (e.g. when to use lambdas and when not to)
• E9 - pycodestyle possible runtime errors caused by syntax changes across the PEP standards
• F - the complete list of pyflakes linting rules and formmating conventions
• C90 - All of mccabe's code complexity rules
• I - issort import grouping rules
• RUF - all of the ruff linting and formatting rules

If you remove the RUF rules, the same effect could be achieved by installing pycodestyle, pyflakes, pyflakes-mccabe, and issort. However, this is why most people choose ruff. The fact that you can implement many different linting/formatting rules from many different linters/formatters with one tool.

A complete list of rules that can be used can be found here: https://docs.astral.sh/ruff/rules

[robyww]

I want to hold off on the PR. The idea is fine but we want to have some time to evaluate coding practices. I don't want to jump into something that i have not had time to think about.

Based on resources this is probably not going to happen very fast.