One thing that all programmers and developers fear is working in someone else's code. Whether it is adding a feature or tracking down a bug, going through a foreign chunk of code can be confusing and frustrating at best. The intent of any script is best understood when it's created and quickly forgotten after. Combine that with differing styles and practices between programmers and you have a hefty task that few experienced people would want to tackle.
There are many ways that development teams attempt to circumvent this issue, usually involving implementing best practices or strict standards. While this may work in some cases, I try to think about it in a bit more liberal sense... Every coding rule will eventually bump into special cases that will cause degradation of the standards. Instead I try to write my code to be read by humans, not computers.
Thinking of code this way can be a bit radical. Most traditional developers go to school and learn how to write code in such a way that computers can parse and understand it, focusing on acceptable syntax or allowed parameter usage. Computers can compile many different formats as long as the script follows a few basic rules. They are looking for specific words to trigger actions, much like an instruction manual or utilitarian document.
Humans don't read for the words, we read for the ideas and intent locked away behind the words. Proper sentences or even spelling isn't important, but the purpose and depth, as well as the ease of understanding, is. This does not excluding coding for a computer, just like writing an engaging story does not automatically mean grammar and spelling gets thrown out the window (unless you're e.e. cummings, that is).
So, what does this mean? You should write your code as if you were telling a simple story to future developers. Well written code is not a product of sticking to strict standards or rules. It is clean, understandable, and semantic, expressing its intent effortlessly. Good code is written for the human, not just the computer.