8 tips for the aspiring Drupal developer

Open source is really great. You get to cherry pick from some of the best software out there and build neat stuff with it, fast. Most open source projects will also encourage you to contribute your own work back to the project. Supposedly, so others can benefit from your work.

While that's often an easy, karma-scoring move, it can have some unintended, annoying consequences. For example, people might start sending in bug reports for your code or may offer suggestions on how to improve it. Even worse, meddling know-it-alls may even offer to 'help' with development and do things with it that you never intended. Some projects, like Drupal, even trick you into such forced participation, by automatically supplying issue trackers, RSS feeds, revision control and other, undesirable community interaction.

Luckily, there are several things you can do to keep those pesky contributors away altogether. You can participate in open source without suffering any of its extended effects. Here are some concrete tips for the aspiring Drupal developer. Of course, a true creative will find novel ways of keeping their open source involvement to an absolute minimum!

1. Using an existing platform can be daunting. If it does something weird that you really can't explain, just work around it. You have better things to do. Warn others away with a comment that explains that you "Don't know why, but with this, the problem goes away." Avoid getting help from the original coders: they were the ones that broke it, remember?
2. Lift pieces from the core and change them. Drupal core provides a rich platform, but the core developers are often short-sighted. For example, several key API functions contain so-called 'security measures' that often just get in your way. Feel free to copy code from core and tweak as needed. Slap a mymodule_ prefix on the function name and you're good to go. Comments about what you tweaked are unnecessary—people can just use diff. And, unlike core, your copy will never be broken by 'fixes' from the community.
3. Include everything but the kitchen sink. If your project needs several related features, group them together into one big module. This ensures that others will always see something they don't need and can't easily get rid of. The idea of serious remodeling in foreign code is an easy turn-off.
4. Forget about backwards compatibility and upgrade paths. If it works for you, that's good enough. Besides, if someone else needs to keep their data, they can still figure out the changes on their own if they're determined. Extra points scored for ensuring that your module can only be installed correctly on a blank site, as this ensures low uptake.
5. Avoid conforming to coding conventions. There's nothing like non-standard names and confusing syntax to make that first read through of the code just that little bit more annoying. And really, why should you conform to the whims of a bunch of like-minded zombies?
6. Skip code comments when possible. As the original author, you already know what the code does. Plus, leaving out Doxygen sections for functions is a great way to make it harder for someone to 'get the big picture' and see how your code fits together. If you must leave a comment as a reminder, don't use sentences, but just slap some related keywords together. Avoid verbs, as they easily expose data relationships and control logic.
7. Don't make it localizable. If you don't speak English, you can even code directly in your native language, and save yourself a lot of trouble translating later. This means you also don't have to deal with those annoying Localization APIs that are over-engineered only to handle the moon language of some godforsaken mountain pygmies anyway.

8. If you must, obfuscate and bloat. Some projects are just too large, trendy or otherwise high-profile to not attract a crowd. In this case, going through the trouble of making your code more verbose and complicated is often needed to keep these nosy people at bay. Go through the extra effort—it's worth it.

   Some of the better methods include:

   • Clustering pieces of your code together in large mega-functions with no clear delimiters.
   • Writing out all your control flow in long, repeated logic structures that contain as many squares from the truth table as possible.
   • Keeping local data in static and global variables, for much longer than needed.
   • Subtly misnaming functions, methods and variables for maximum effect: a _check() that doesn't, a _save() that deletes or a _form() that returns a table can wreak havoc in the most unexpected places.
   • Creatively using APIs for accessing internal or otherwise unrelated data. The API reference is a great resource for finding such useful backdoors.

With these simple guidelines, you'll keep even the most seasoned contributor far away before they ever think of submitting a patch!