Monday, 18 April 2016

Falsehoods Programmers Believe About PEP 8

We're computer programmers. We spend our days warping reality to our purposes, and then leaving behind a textual representation of the exact type of warping so the next person can use our modified reality. Over the years, many MANY Python programmers have looked at a document called PEP 8 and misunderstood it, just as many programmers misunderstand time, or people's names. The same PEP 8 misconceptions crop up over and over again, and after some discussion on python-list, I've collected these commonly-held fallacies.

Remember, all of these assumptions are wrong.

  1. All Python code should follow PEP 8.
  2. If you use a tool named pep8, your code will be PEP 8 compliant.
  3. If your code is PEP 8 compliant, a tool named pep8 will accept it.
  4. The Python Standard Library is PEP 8 compliant.
  5. Okay, at least the new parts of the standard library are PEP 8 compliant.
  6. PEP 8 compliant code is inherently better than non-compliant code.
  7. PEP8-ing existing code will improve it.
  8. Once code is PEP 8 compliant, it can easily be kept that way through subsequent edits.
  9. PEP 8 never changes.
  10. Well, it never materially changes.
  11. I mean, new advice, sure, but it'll never actually go back on a rule.
  12. The line length limit is obsolete in an age of high-resolution displays.
  13. Okay, but if you disregard side-by-side windows, lines of code can be arbitrarily long without hurting readability.
  14. Well, maybe not several hundred characters, but surely 120 characters of code on a line is easy enough to read.
  15. The only valid white space is line breaks and U+0020 SPACE.
  16. Okay, U+0009 TAB when lining up columns, but no other white space.
  17. Oh, come on, no-one would use U+000C FORM FEED in source code.
  18. Everyone uses the same sort of tools (visual text editors) to read and write code.
  19. Ignoring the few weirdos who can cope with their own bizarre choices, every NORMAL person uses the same sort of tools.
  20. Alright, everyone at my organization will use the same tools. I can mandate that, so it must be true.
  21. Readability is an inherent quality of code. It doesn't matter who reads it, good code is good code.
  22. Avoiding the "Names to Avoid" is a sure and simple way to make sure your identifiers aren't confusable.
  23. Unicode is good for identifiers.
  24. Unicode is bad for identifiers.
  25. Unicode is optional for identifiers.
  26. You know what I mean. I'm talking about *non-ASCII* characters. And you shouldn't use them.
  27. PEP 8 is a tool for denying patches/pull requests that you should reject.

As with the articles I'm riffing off, every one of these is false, and I can give examples. And this is far from an exhaustive list. If you want to avoid the worst of the errors, start by reading the actual document (not some tool that borrows its name), particularly the section entitled "A Foolish Consistency is the Hobgoblin of Little Minds".

With thanks to Ben Finney and Dan Sommers for contributions to the above list.