Djangocon: Conformity and you - a question of style - Greg Chapple¶

Tags: django, djangocon, python

(One of the summaries of a talk at the 2015 Djangocon EU conference).

Greg Chapple works half his time on Django projects, half on Rust projects.

Some things you’ll probably never hear: “Can’t wait to fix some pep8 violations today”. Style conventions probably aren’t the sort of thing you take into account when picking a language or a framework.

Every line of code follows some sort of style convention. Intentional or not. The style of our code can identify us. Same as with this talk: Greg speaks with a slight Dublin accent, by default.

Something to ask yourself: if you look at a piece of code inside your company, could you identify the person that wrote it?

Let’s get back to Greg’s accent and the way he speaks. How did he come by this? Where he grew up, of course. The people he’s around regularly. You can change it, though. He spend two weeks in the USA and when he came back he got funny looks for some of the US pronouncement that krept into his vocabulary.

The same with your code style! You’re influenced by the code you’re surrounded by. If you want to make changes, it takes quite some effort to do it. Learning to use list comprehension instead of for loops, for instance.

Your style should be consistent. Using single quotes in one place and double quotes on the next line, that looks bad. Spaces after a comma in some places (=pep8) or not.

If you have to switch from one project to another, you’re helped a lot if both projects use the same style. That’s where style guides come in. PEP8, jshint, flake8. Corporate guides. Look for support for those in your text editor to make it easy for you to use them. If you look at the download numbers for these text editor extensions, they’re very popular (and rightfully so).

Interesting fact: people take comments about their coding style much better if it comes from a tool as opposed to from a human being :-) Having a tool in place to tell you about code style violations is very valuable as it removes lots of possible unfriendly interactions.

A nice quote from pep8: One of Guido’s key insights is that code is read much more often than it is written. As PEP 20 says, “Readability counts”.

Greg looked at the django source code, hoping to find some nice glaring inconsistencies, but the django code is pretty good! :-) He did find some small issues and showed them as examples.

Sometimes you should allow some slight breakage to actually improve readability.

If someone else will be working on it, make sure it looks good.

If the code looks dirty and non-consistent, it doesn’t help to make you trust the actual work the code does. Doesn’t the lack of attention to how it looks mean that the actual code is not well-designed? Maybe, maybe not. But the lack of attention could easily have been there in some of the algorithms or the security declarations, right?

Your code speaks about you. You, as a professional developer. What does it tell about you?