Not too long ago, I posted a blog entry about 5 reasons for using a virtual machine for Drupal development. At the suggestion of some commentors, I have started looking into using Vagrant to manage my VMs. There is an excellent Drupal Vagrant project that provides a great starting point. This article explains how to begin with that and modify it to suit your own needs.

The Drupal codebase upon which I work is now over a million lines of code (excluding whitespace and comments). It sounds impressive. But the reality of the matter is that the combination of lots of code and the Drupal way of doing things makes it not impressive, but a maintenance nightmare. Nobody on the current team knows what all of this code does or what it is for. Even limiting things to the custom modules, there still is no longer any member of the team who knows the code well. This, of course, isn't a criticism of the team or even of the platform, but a reflection on what happens when a codebase balloons over the years.

Reading Steve Yegge's post entitled Code's Worst Enemy hit home the concern I have with our code -- and with Drupal in general. (Update 10/29/2011: Steve Yegge's the guy who accidentally posted the Amazon/Services rant on Google+, and who unintentionally "quit his job" in the middle of his presentation at OSCON.)

I suggest reading the entire blog post on its own, but here are several salient details that need explicit mention, and that have a Drupal context:

• While some languages (Java) may exacerbate the problem, clearly ballooning code can happen in any language. And with a semi-opaque execution sequence (as we have in Drupal), the problem can be compounded by the fact that one cannot determine at a glance what code might be executed on a given execution. To know what code will be executed on a given request, you must know not just core and your own modules, but all of the installed modules.
• Design Patterns might deserve a measure of skepticism. Steve's point is that relying upon them can introduce needless complexity. He uses Dependency Injection as an example. Too often, design patterns are introduced for their own sake or because they look similar to what we want to accomplish. But then the need to (re-)architect in terms of the pattern sometimes overshadows the original goal of accomplishing a task.
• Copy-and-Paste (CAP) code is bad. Obviously. But because all of Drupal is a public API, I often see developers choosing to CAP code from function body to function body because they think that is more elegant than providing highly-contextual stand-alone functions that might be mistaken by other developers as "generally useful". (No, prefixing functions with underscores is NOT a good alternative. Lately, I've been encouraging developers to underscore all functions that aren't hooks or constructed callbacks because it's too easy to get hook/namespace collisions otherwise.)
• Unfortunately, Steve doesn't talk about YAGNI ("You Ain't Gonna Need It") as a good design principle, but the converse of YAGNI -- that tendency to attempt to solve all possible cases before there are any actual cases -- is a dangerous tendency in software developerment that must be countered in the name of simplicity and maintainability.

In hindsight, I'm surprised how long it took me to develop a strong appreciation of code formatting standards. It's not that I haven't followed them all along (most IDEs and editors do the lion's share of that for you). What surprises me is that I never really appreciated the value of following them. But managing a codebase of over a million lines makes it readily apparent that coding standards are a big boon -- and that lapses in those standards adversely impact the entire team.

The primary reason for coding standards is this: humans are worse at syntax parsing than machines are. Coding standards exist to make the code easier for humans to work with, and they do this by making the code more amenable to visual scanning.

There are four benefits to be gained from following coding standards: reduction of bugs, preventing new bugs, lowering the learning curve, and easing long term maintenance. I discuss them below.

I recently started working on a few Node.js applications. Coming most recently from PHP (and Drupal in particular), I found the transition to Node.js to be surprisingly easy. Pleasurable, in fact. But I had to learn to think differently about a few things.

Below I list the five things I think every PHP developer should know about Node.js.

In years past, I used to do my development on a local machine, and then push my work to a remote server for testing. About two years ago, though, I switched my environment. I began using virtual machines instead of physical servers. Configuring them for Drupal, I could do my Drupal development locally, and then do advanced testing on my virtual machine.

In this article, I give five reasons why I believe Drupal development can be enhanced through using VMs.

There are very good uses for Switch statements. They can be great for nesting logic. But sometimes they are used as a way to (essentially) map a name to a value. In such a scenario, the body of the case is just a simple assignment.

After noticing this pattern a lot recently, I thought I'd benchmark it against the obvious replacement candidate: a hash table lookup. PHP arrays are more like ordered hash tables. For that reason, they provide very fast random access. Are they faster than a switch statement?

I ran two tests. In the first case, I assumed no default. In the second, I assumed a default. The conclusion: Arrays are faster. Read on for the details.

I like the fact that PhpDocumentor is implemented in PHP. I like that it has a mature feature set, and has a long history of support. But when it comes to generating API documentation from PHP, I am preferring Doxygen these days. Here are five reasons why.

I'm continually surprised by PHP programmers who argue tooth and nail that a PHP "array" is a "real array". These same programmers, who often program in at least one other language (JavaScript), seem confused over what an array is and how it ought to work. (One even referred to collections classes in other languages as "needless bloat," a telling symptom of this misunderstanding.) Conversely, new PHP developers who come from other languages are often confused by the fact that PHP arrays don't work as expected. Strange things happen to array ordering and such. The confusion can be cleared up at the terminological level. The simple fact is that PHP arrays are not arrays in the traditional sense. They are ordered hash tables. I will explain with several examples.

Yesterday, I had the privilege of hanging out with Ryan and Mike from DrupalEasy. We had a great time talking about recent changes in Drupal 7's bug release cycle, DataTables, Schema.org and other stuff. We talked a little about the Aloha Editor, too -- a project my friend Henry Bergius is involved in.

Two years ago I was on DrupalEasy talking about my Drupal 6, JavaScript, and jQuery book. This time we talked about Drupal 7 Module Development. I figure I might as well plan now on doing an episode in two years on a Drupal 8 book.