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 review¹, 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:

https://ep2016.europython.eu/en/events/sessions/

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"¹ 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.

Recently, I've read an interesting article¹, explaining why the strncpy function in C is not safer than strcpy. The post was very interesting, but what's more, it suggested an alternative idiom for copying strings in C, that might probably be the way to go.

Later, in another article² that compared some functionality in C, Python and Go, one of the comments pointed out that very same idiom. That grabbed my attention, so I decided to try it in an example.

It is well-known among Python developers (or at least, it should be), that is a bad idea to import everything from a module, for example by doing from <module> import *.

The idea on this post, is to highlight and gather the reasons why this is a bad practice, in order to collectively identify many undesired effects. However, without losing pragmatism, in case there are some odd reasons why this might be acceptable, I will also mention them, if any. Let's see where we get.

This post is based on a gist I wrote a while ago, about why is not a good idea to pass default mutable objects as parameters in python function definitions.

While the gist is explained through an example that uses lists, the principle is applicable to all sorts of objects (dictionaries, sets, etc.).

{{ gist(owner=“rmariano” id=“7593536” filename=“function_parameters.md” )}}

If you are an experienced python developer, you probably knew this caveat, nevertheless is something interesting to show to new python developers, and to remember even if you have been writing code in Python for years.

This post is inspired on an issue I once found, while I was using a well-known library in Python for parsing YAML files. The problem was that when it was loading the content of the file, the result was not coherent, because sometimes it returned the content as a python dict, but if the file was empty, the return value was None.

Do you notice something odd here?

What if I want to use the result? I cannot do it safely, for example: