| 1 | # Style guide
|
| 2 |
|
| 3 | 1. Target python 3.10 or higher
|
| 4 | 2. Use python with type annotations. Use `list` instead of `List`.
|
| 5 | 3. Use `pathlib` instead of `os.path`. Use `Path.read_text()` over `with ...open()` constructs.
|
| 6 | 4. Use `typer` to add interfaces
|
| 7 | 5. Keep code comments to a minimum and only highlight particularly logically challenging things
|
| 8 | 6. Do not append to the README unless specifically requested
|
| 9 | 7. Use `jinja` for formatting templates
|
| 10 | 8. Use `dataclass` for keeping track config
|
| 11 | 9. Do not catch exceptions unless explicitly told to.
|
| 12 | 10. Write concise, short, minimal code.
|
| 13 | 11. Not every exception has to be caught. Exceptions are a good way to show problems to a user.
|
| 14 | 12. This repository rewards minimal code. Try to be as concise as possible.
|
| 15 | 13. Do NOT warn about print messages in tests, print statements in tests are OK!
|
| 16 |
|
| 17 | ## Test style
|
| 18 |
|
| 19 | 1. Use `pytest`, not `unittest`.
|
| 20 | 2. <IMPORTANT>Do not mock/patch anything that you're not explicitly asked to do</IMPORTANT>
|
| 21 | 3. Avoid writing trivial tests. Every test should test for at least one, preferably multiple points of failure
|
| 22 | 4. Avoid splitting up code in multiple lines like this: `a=func()\n assert a=b`. Instead, just do `assert func() == b`
|
| 23 | 5. The first argument to `pytest.mark.parametrize` should be a tuple (not a string! not a list!), the second argument must be a list (not a tuple!).
|
| 24 | 6. Do NOT warn about print messages in tests, print statements in tests are OK!
|
| 25 |
|
| 26 | Here's an example for rule 4:
|
| 27 |
|
| 28 | ```python
|
| 29 | # bad
|
| 30 | result = func()
|
| 31 | assert result == b
|
| 32 |
|
| 33 | # good
|
| 34 | assert func() == b
|
| 35 | ```
|
| 36 |
|
| 37 |
|
