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.
Plone, as an open source software, is developed and maintained by thousands of developers from around the world. Therefore our Plone development team gets regularly tapped for help to make a Plone site faster or add new functionalities to it.
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.
Code Standards To The Rescue
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' Plone developers and other Plone Development partners.
Code standards also make finding similar chunks of code across a large code base much easier. This saves our Plone Development team valuable time when working on large development projects. Not to mention the fact that educated clients often 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.
Why Use PEP8 In Your Plone Development
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 Plone development team's top two PEP8 pet peeves: 1) lines of code should be less than 79 character long so as to have 3 files open side by side on your screen, and 2) you should organize import statements by external package to make dependencies explicit.
How To Start Incorporating PEP8 In Your Daily Plone Development Routine
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 Plone development team on PEP8 techniques on a regular basis. It usually is a great idea to appoint one of your programmers as your PEP8 champion.