All the talk about coding standards is *mostly* geared towards the professional software developers, those of us who work on large projects with a team of others, and who do that every day. If you're someone who is just willing to dig in and contribute, please continue to do so, feel free to read this article, but it's not really for you. But let's say you're a programmer. You write great code, that does a lot of good stuff! If you're on the Drupal project, you've probably submitted several patches and even contributed a few modules. I believe that when I’m working on someone elses code, it’s better to keep my changes to the necessities. I don’t know this code as well as the author, and the more I change, the more likely it is that I’m going to break something. Frequently however, I see code that is so different than the project coding standards, I find it very hard to just fix what’s broken.

(A short aside, I've been programming for 20+ years and I've been part of several large projects, and every project has it's own coding standards. So when I say "the project coding standards", I'm referring to the coding standards for whatever project I happen to be working on at the time. At this moment, it's the Drupal project.)

... When working on non-standards compliant code, I find it very hard to just fix what's broken. It's either a bad habit or a good one -- I'm not sure which. But, I believe that software is as much an art as a science, that good software not only works and has a nice user-interface, but good code also looks good to other programmers. Code not written to standards is ugly to me. The consequence is that I either:

• (a) do not work on code the is non-standards. This is often not an option, but if we're talking about contributing hours for the love of it, I'd take a pass on non-standard code,
• (b) try very very very hard to not change the non-conforming code, but this often takes me twice or thrice as long because as I said above, I just can't help myself, or
• (c) make larger changes that not only address the bug but also fix the non-conforming standards. These patches have a higher risk of breaking functionality and would be better to avoid. (Patches intended to make code standards conforming should be done separate from other changes.)

But I'd prefer a fourth option:

• (d) IF ONLY the original authors would write code to the coding standards, I would want to contribute, I wouldn't have to spend twice as long contributing, and I wouldn't have to worry that I've changed too much!

And now a few specifics about the Drupal project...

If you want to get code accepted by core, they are very picky about this stuff.

(Don't blame me. I didn't write the coding standards, I wrote the module that helps you comply with the coding standards!)

... It would be good to just learn the rules and let standards conforming code fly off the tip of your fingers. I learned the rules while writing the coder module. But you can use coder to help learn the rules too. So here are some simple suggestions:

• Learn the Drupal coding standards, especially the spacing, and spacing around quote strings
• Use coder, but realize that coder only makes recommendations, you should be the final arbitrar
• Make sure your editor does not write out tab indents, but rather writes tabs indented to two spaces
• Use single quotes when possible. Have you ever noticed or wondered why all the array hash names are single quotes? Double quotes have to be scanned for more substitutions and as such have a slight performance consequence.
• Learn the rules of operator precedence so you can avoid putting extra parenthesis () around conditions that don’t need them, i.e., here is an example of extra parenthesis, if (!(checksomething()) )
• Don’t put bracketed code on a single line, i.e., here is an example of what not to do (use newlines so this is 3 lines of code) if ($somthing) { dothis(); }
• Avoid extraneous assignments, i.e., $output = ‘return this’; return $output; should just be: return ‘return this’; unless the extra assignment really helps with readability
• Separate your code logic from the user display by learning how to use FAPI and theming. Try to avoid using HTML in your code logic, instead use CSS, use <div class="yourclass"> or <div id="yourid">

Getting back to the original tone. You're a great programmer. Drupal needs you and you need Drupal. I hope these tips will help you become an even better programmer and a bigger contributor to the Drupal project. I'm as non-conformist as the next guy, ... probabably a little more so. But coding standards help everyone. The code is easier to read and maintain. It's not just functional, it's beautiful, and other people work on it.