|
13 | 13 |
|
14 | 14 | # %% [markdown] |
15 | 15 | # ## Coding Conventions |
16 | | - |
17 | | -# %% [markdown] |
18 | | -# Let's import first the context for this chapter. |
| 16 | +# |
| 17 | +# Let's import a few variables from context.py that will be used in the following lesson. |
19 | 18 |
|
20 | 19 | # %% |
21 | | -from context import * |
| 20 | +from context import ( |
| 21 | + sEntry, |
| 22 | + iOffset, |
| 23 | + entry, |
| 24 | + offset, |
| 25 | + anothervariable, |
| 26 | + variable, |
| 27 | + flag1, |
| 28 | + flag2, |
| 29 | + do_something, |
| 30 | +) |
22 | 31 |
|
23 | 32 | # %% [markdown] |
24 | 33 | # ### One code, many layouts: |
25 | | - |
26 | | -# %% [markdown] |
27 | 34 | # |
28 | 35 | # Consider the following fragment of python: |
29 | 36 | # |
@@ -219,43 +226,48 @@ def method_name(a_variable): |
219 | 226 | # |
220 | 227 | # There are automated tools which enforce coding conventions and check for common mistakes. |
221 | 228 | # |
222 | | -# These are called **linters**. A popular one is [pycodestyle](https://pypi.org/project/pycodestyle/): |
223 | | -# |
224 | | -# E.g. `pip install pycodestyle` |
225 | | -# |
226 | | -# |
227 | | -# |
| 229 | +# These are called ** formatters** and **linters**. Some widely used linters and formatters in the Python ecosystem ar - |
| 230 | +# - [pycodestyle](https://pypi.org/project/pycodestyle/): check your code against PEP8 |
| 231 | +# - [pylint](https://www.pylint.org/): useful information about the quality of your code |
| 232 | +# - [black](https://github.com/psf/black): code formatter written in Python |
| 233 | +# - [ruff](https://github.com/astral-sh/ruff): blazing fast code formatter and linter written in Rust with ideas borrowed from Pythonic linters and formatters |
228 | 234 |
|
229 | | -# %% magic_args="--no-raise-error" language="bash" |
230 | | -# pycodestyle species.py |
231 | 235 |
|
232 | 236 | # %% [markdown] |
233 | | -# |
234 | | -# |
235 | | -# |
236 | | -# It is a good idea to run a linter before every commit, or include it in your CI tests. |
237 | | -# |
238 | | -# |
| 237 | +# Most of such tools can be directly used on Python files / repositories using a CLI utility. For instance - |
239 | 238 |
|
240 | | -# %% [markdown] |
241 | | -# There are other tools that help with linting that are worth mentioning. |
242 | | -# With [pylint](https://www.pylint.org/) you can also get other useful information about the quality of your code: |
243 | | -# |
244 | | -# `pip install pylint` |
245 | | -# |
| 239 | + |
| 240 | +# %% magic_args="--no-raise-error" language="bash" |
| 241 | +# pycodestyle species.py |
246 | 242 |
|
247 | 243 | # %% magic_args="--no-raise-error" language="bash" |
248 | 244 | # pylint species.py |
249 | 245 |
|
| 246 | +# %% magic_args="--no-raise-error" language="bash" |
| 247 | +# ruff check species.py |
| 248 | + |
250 | 249 | # %% [markdown] |
251 | | -# and with [black](https://black.readthedocs.io/) you can fix all the errors at once. |
252 | | -# ```bash |
253 | | -# black species.py |
254 | | -# ``` |
255 | 250 | # These linters can be configured to choose which points to flag and which to ignore. |
256 | 251 | # |
257 | 252 | # Do not blindly believe all these automated tools! Style guides are **guides** not **rules**. |
258 | 253 |
|
259 | 254 | # %% [markdown] |
260 | | -# Finally, there are tools like [editorconfig](https://editorconfig.org/) to help sharing the conventions used within a project, where each contributor uses different IDEs and tools. There are also bots like [pep8speaks](https://pep8speaks.com/) that comments on contributors' pull requests suggesting what to change to follow the conventions for the project. |
| 255 | +# |
| 256 | +# It is a good idea to run a linter before every commit, or include it in your CI tests. |
| 257 | +# |
| 258 | +# [`pre-commit`](https://pre-commit.com) allows developers to add tools like linters and formatters |
| 259 | +# as git hooks, such that they run before every commit. The hooks can be installed locally using - |
| 260 | +# |
| 261 | +# ```bash |
| 262 | +# pip install pre-commit |
| 263 | +# pre-commit install # provided a .pre-commit-config.yaml is present in your repository |
| 264 | +# ``` |
| 265 | +# |
| 266 | +# This would run the checks every time a commit is created locally. The checks will only run on the files |
| 267 | +# modified by that commit. |
| 268 | + |
| 269 | + |
| 270 | +# %% [markdown] |
| 271 | +# Finally, there are tools like [editorconfig](https://editorconfig.org/) to help sharing the conventions used within a project, where each contributor uses different IDEs and tools. |
| 272 | +# There are also bots like [pep8speaks](https://pep8speaks.com/) and [pre-commit.ci](https://pre-commit.ci) that comments/run checks on contributors' pull requests suggesting what to change to follow the conventions for the project. |
261 | 273 | # |
0 commit comments