Clean code in Python, second edition has been published, and here are the main highlights!
The main change is that the book has been updated to Python 3.9. The previous
edition was started when Python 3.6 was new, and by the time it got published,
Python 3.7 was just recently released. Since then, a lot has
changed in Python and the book addresses the new features.
In our profession, attention to detail is of utmost importance. Any good software engineer understands that details matter a lot, as they make the difference between a working unit or a disaster1.
This is why clean code is not just about formatting or arranging the code. It's neither a foible. It is instead, paying attention exactly to those details that will make a big difference in production.
Let's see some examples of this in Python.
This is an opinion I sometimes remember when seeing some code. Don't take it as a strong advice, or a rule, but instead as a general guideline that might help you to improve the code slightly.
On this post I will share a tiny and opinionated argument about why there are usually better things to do in the code instead of just pass.
Disclaimer: I am not saying that pass should be banned from the language, or that is an anti-pattern, or a bad idiom. Nothing like that. If that were the case, it wouldn't be a keyword (and we know how few keywords Python has, and how hard it is to introduce a new one, so it's there for a good reason).
It looks like there are a lot of opinions or assumptions about unit tests and code coverage, most of them confusing of biased in several ways. For example, I've heard or read things like "this is fine, it has X% coverage", or "checking for coverage on pull requests doesn't help", or "dropping the coverage level is not an issue", and many more of the like.
This article aims to shed some light on the issue of unit testing with and code coverage. Hopefully by the end of it, we'll get an idea of which of the previous statements are right and which are wrong (spoiler alert: they're all wrong, but for different reasons).
After watching a talk about code review1, from the last EuroPython, I got some ideas that I'd like to summarise.
The first one is a point I made on my talk about clean code in Python, about running style checks (PEP-8, for example), automatically as part of the CI. This has several rationales, the first one being that it's the sort of thing machines should do, and not humans. Having software engineers reviewing the tabs, spacing, and such, is just a wasted effort (not to mention, wasted money). As I mentioned on the conclusions during my talk, we should focus on the readability of the code in terms of the logic, by asking ourselves things like "does this code make sense?", rather than "is the space before the comma correct?". Remember, code is for humans, not machines, it's a means of communication with the development team.
I am glad to inform that I will be speaking at EuroPython 2016 conference.
My submission about clean code in Python was accepted, so in the next edition of EuroPython 2016, in Bilbao, Spain, I will talk about clean code principles for Python. Here is the abstract:
https://ep2016.europython.eu/conference/talks/clean-code-in-python
The full list of talks is available at:
If you are interested, subscribe to the EuroPython blog and Youtube channel. I will include more details in a separate post.
This is a rule I always encourage in software development. Moreover, I consider it to be something that has to be included in every coding guideline of a good project.
There are several reasons for this, but probably the best explanation can be found in the book "Clean Code"1 by uncle Bob, on which explains that the code, gets outdated (rotten) with the rest of the surrounding code, and hence it makes a place for confusion, leading to an error-prone spot.