When I Used PEP8 To Fuck Up Code2016-07-19 #python #pep8 #readability
We "inherited" some Python code recently. Although another team was working on
it, we now should support it and keep it going. The previous team at least
tried to use Pylint and follow PEP8. And I say "tried" because their
pylintrc has a couple of exceptions and their PEP8 extended the
maximum column to 100.
Quick pause here 'cause I know a bunch of people will complain with a "But monitors these days are very large and you don't need to focus on column 80; we don't use CGA anymore, old person!". The thing about the maximum column at 80 is not about "being visible on every CGA" but actually a measure of readability: If you speak shorter, concise sentences, people will get the idea quickly; if you keep an stream of words non-stop without reaching a conclusion and without any punctuation to keep the ideas flowing, you will end up with something that it is easier to forget and which the central idea will be lost (and I freaking hope you got what I just did). It's tiring to read a very long sentence; it's easy to keep the context on a short sentence.
In the spirit of "proper" PEP8, I reformatted one of the failing tests to follow the 80 column limit. And now the code looks like crap. And I'll commit like that. It's not because I hate my coworkers, but to point out that, because it's a pain to read, it means the structured of the code is too complex. If someone comes and say "damn, this test is hard to read", I'll be able to point that it is not the test that it is hard to read, but the code that reached the point where its complexity is leaking to the test code; it is now a good time to refactor this to simplify things and make them easier to read.
Not that we can simply stop working and fix the damn architecture of it, but we can at least keep this beast around till everybody gets pissed and realize it desperately needs a refactor.