Hardly any software is maintained by the original author for its whole life and some claim that 80% of the lifetime cost of a piece of software comes from maintaining that code.
Open source software is developed and maintained by thousands of developers from around the world. Therefore our Python development team gets regularly tapped for help to make existing systems faster or add new functionalities to existing apps.
Picking up code that is badly written is like picking up a book in another language. Imagine reading your favorite book in English if the words were written from right to left. Scanning is hard. You have to read every single word. Understanding the story plot (i.e. code) is a much slower process and much less enjoyable experience.
Code validation (i.e. testing) is also a necessary activity that sends developers on a hunt for what might be causing a specific bug. If the code is clean, finding and resolving the error is much faster.
In short: bad code is both evil and expensive to both a development team and their client.
Fortunately, standards are here to prevent issues that could arise from bad code. Code standards define code layout (indentation, spacing, blank lines, line length, etc.), naming conventions, comment usage and code structure.
Senior Plone Developer David Blewett explains: "Code standards are all about making code look consistent. When people from several projects all use the same guidelines, you can scan a given piece of code for a section that you are looking for much more easily." Enhanced code readability allows developers to find errors more easily and more quickly, and collaborate with each other more effectively. This is crucial for Six Feet Up as we closely collaborate with our clients' Python developers.
Code standards also make finding similar chunks of code across a large code base much easier. This saves our Python Development team valuable time when working on large apps projects. Not to mention the fact that educated clients do require their enterprise software development vendors to follow best practices.
Lastly, if you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create. This speaks to the quality of your work and the reliability of your brand.
PEP8 is a coding convention for Python code that was established in 2001. What we like about PEP8 is that it was written at the language level. PEP8 doesn't explicitly mandate each detail of how to format code. It provides the basis for the big choices (tabs vs. spaces for indenting, indent width, line length, etc). As long as code follows those and is internally consistent, it's easy to read.
Just for fun, here are our Python development team's top two PEP8 pet peeves:
Read the style guide for Python code written by Guido van Rossum and Barry Warsaw. Then watch the talk that Clayton Parker, Senior Developer at Six Feet Up, gave at PyOhio entitled Code with Style (slides are up on Slideshare).
Also read the following article about having a concept of "bad" and "well" formatted code: http://www.joelonsoftware.com/articles/Wrong.html
Finally, leverage a command-line script that you can run to check existing code: PEP8 is released on PyPI so you can install it using your favorite packaging tool (easy_install, pip, buildout).
And make sure to train your Python development team on PEP8 techniques on a regular basis.
Pro tip: appoint one of your programmers as your PEP8 champion.