How I Learned to Stop Worrying and Love PEP8

An important part of programming (maybe the most important part) is reading other people’s code. Unless you’re somehow, single-handedly running an entire company on code you’ve written by yourself, your code will be read and (shock horror) edited by other people.

These other people will have learned to program in different ways, different places and for different reasons than you did and will thus have different ideas about what makes code beautiful. Whether it’s a disagreement about where curly braces should appear after a method declaration, about using spaces or tabs for indentation, or about the choice among camelCaps, snake_case, and kebab-case, time wasted wrangling over standards is time spent away from actually doing the programming.

When I first started here at Opsview, less than a year ago, having just graduated from University, my coding practices were not identical to those used in the company and honestly, not even particularly consistent among bits of my own work. For University coursework, although keeping code technically clean and efficient was a priority, the actual appearance of my code was less important – largely because there was no need to build a codebase readable and usable by others over the long term. When we did do group programming projects, time was usually wasted settling on a style.

Opsview's standardized code guidelines

To avoid such time-wasting deliberations and simplify code review, Opsview has adopted a set of standardized code guidelines for various languages. For the Python code powering our back-end and our newer Opspacks, we stick to Python’s mostly comprehensive “PEP8 -- Style Guide for Python Code". Tools like flake8 let us check how closely our code matches these guidelines. More recently, calls to flake8 and other Python linters have been added to various Python project Makefiles, letting us test code formatting automatically, at build times.

Though technically-valid, this Python code sample is not ideally beautiful.

For our Perl code, we have a more thorough system, using Perl::Tidy to format our scripts and libraries before they are committed to our internal version control system. Unlike with our Python approach, perltidy is actively reformatting our code to meet its style guidelines. Our Jenkins build scripts for Perl projects run perltidy on input code and fail if differences appear, preventing off-style code from being merged in.

That all probably sounds a bit picky, but consistency here is essential. A uniform codebase lets  everyone know what they’re getting when they look at new code for the first time. With no unpleasant newline messes or strange casing of function and method names, no time needs to be spent cleaning up the code before reading it. Learning these styles and sticking to them when joining here took a tiny bit of adjusting to but it was definitely for the best.

PEP8 formatting makes this Python more readable and consistent.

Through the use of a few external tools, the quality of the code remains consistent here at Opsview, letting us iterate more quickly and provide new features without spending time on cleaning up.