I've been tasked with coming up with a written document of coding standards after getting fairly frustrated with myself about having an internal set of rules, but not being able to effectively communicate them. It creates a fairly tense atmosphere where I've become known as the code Nazi, a.k.a. a dick.
Researching effective standards has resulted in an interesting discovery.
My code isn't that great!
The code I write is pretty good, but in looking at models like PSR, I find that it's not always consistent. Maybe there's more to this whole "writing out the standards" thing.
I often find myself walking a very thin line between craftsmanship and time. Whenever I do something that is going out to the community, I force myself to follow the guidelines of that community. Who likes getting rejected commits, right? However, when I write for in-house or clients I tend to sloppy it up towards the middle to end just to wrap it up. Usually by that time I'm way past due and crunching to get to test phase.
I always have the best intentions of cleaning up code later, but the reality is that by the time it's done testing I'm probably neck deep in another project. It makes for a usually horrific throwback when I have to revisit it a few months later to add or optimize some part of it.
Coding standards can help speed up the process of coding, but also prevent rework, which is the initial aim. If I am going to rewrite someone's code before deployment, I need to at least have a better reason why than "it sucked."
I'll try to keep this up-to-date as I progress, and document some new findings and explorations.