No video :(

Kyle Knapp - Automating Code Quality - PyCon 2018

PyCon 2018

Подписаться 21 тыс.

Просмотров 10 тыс.

50% 1

Speaker: Kyle Knapp
Writing quality Python code can be both tough and tedious. On top of the general design, there are many code quality aspects that you need to watch out for when writing and reviewing code such as adherence to PEP8, docstring quality, test quality, etc. Furthermore, everyone is human. If you are catching these code quality issues by hand, there is a good chance that at some point you will miss an easy opportunity to improve code quality. If the quality check can be done by a machine, then why would you even try to catch the code quality issue by hand? In the end, the machine will be able to perform the quality check with much more speed, accuracy, and consistency than a person.
This talk will dive into how existing open source projects offload and automate many of these code quality checks resulting in:
- A higher quality and a more consistent codebase
- Maintainers being able to focus more on the higher level design and interfaces
of a project.
- An improved contribution process and higher quality pull requests from
external contributors
By diving into how these open source projects automate code quality checks, you will learn about:
- The available tooling related to checking code quality such as `flake8`,
`pylint`, `coverage`, etc.
- How to automate code quality checks for both a development and team
setting.
- First-hand accounts of the benefits and lessons learned from automating
code quality checks in real-life open source projects.
Slides can be found at: speakerdeck.com/pycon2018 and github.com/PyCon/2018-slides

Опубликовано:

12 авг 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 11

@stalinthomas9850 3 года назад

06:38 flake8 10:21 pylint 14:54 coverage 16:53 Code quality tools ecosystem 18:50 Automating for local environment 21:22 Automating for a team/project environment 23:24 Benefits of automated quality check setup 24:20 Best practices 27:30 Recap

@ralienpp 6 лет назад

Thanks Kyle, this was very informative! I have some questions - why did you chose to use a Make-file to do that, as opposed to a bash script or something else?

@kyleknapp2077 6 лет назад

Thanks! Glad you liked the talk. We use a makefile mainly because it is just something that my team is most familiar with and use most often in other projects. Makefiles are nice because they keep all of your logic in one place (say as opposed to a bunch of bash scripts) and make it very easy to run a specific rule (i.e. all you have to do is run “make ”). However, the makefile could have been easily replaced with bash scripts or tox (Aside: tox is nice too because it is similar to a makefile but you can have it run for different Python environments automatically). In the end, it is up to on how you want to approach it as the point of it is to enable better organization of your checks and make it very easy to run them. So, if you do find something that achieves those two goals that you like, I say go for it.

@ralienpp 6 лет назад

After some experimentation, I settled for Makefiles as well, they are quite convenient. Do you know of a way to wrap the calls to pylint in such a way that the build fails if there are errors, but doesn't fail if there are recommendations on style, naming conventions, etc? For example, an easy way to accomplish this is to run pylint with `--disable=C,R,W`, but this doesn't run those checks at all. I would like to run them, so I can see the output and the recommendations, but in a way that they don't interfere with the final outcome. Is this a common practice?

@vcool 6 лет назад

ralienpp You can probably alternatively configure pytest to run the tools of your choice. For this you would have to install each relevant pytest plugin.