code

Couple things happened today (Friday, of all days):

1. My old blog hosting company sent a "we are shutting down" notice. Out of curiosity I clicked through and quickly found myself reading 5-year old posts. One of them was ranting about code maintenance.
2. A friend tweeted a link to a blog post by Rohan Singh: Isn't All Coding About Being Too Clever? where he's also talking about maintainable code (with a different perspective).

This got me thinking...

In majority of software engineering literature, "maintainability" of code is hailed as sacred. It's easy to relate to the sentiment: no code gets written once and then forgotten. When you ship code, you give it birth, but the actual life of that code is only just starting. You want to make sure your code spends its life well -- goes to college, marries the right person, and makes the "parents" proud when other people have to deal with it (that's the maintenance part).

Except, much like with kids, your plans for your code almost never work out as initially intended. If you are smart enough you accept them just the way they turn out to be (at least - code, if not kids) , without trying to be a control freak. And that's where this obsession with "maintenance" can become a problem.

It's a pretty common need to format an array as a proper comma-delimited string for use in SQL's "WHERE ... IN" clause. Following is a simple solution that demonstrates how closures in PHP 5.3+ make writing such code pretty elegant. A unit-test is included to demonstrate several edge cases:

For the [hopefully very infrequent] times when you still need to deal with CVS, in 2010, and [god forbid] fix something you messed up there, here's how you can revert an accidental commit back to the previous version.

First find the revision you need to revert back to by running:

cvs log screwed_up.code

Once you have the revision number you want to switch to (say, 2.1.2.1), run:

cvs -Q update -p -r 2.1.2.1 screwed_up.code > screwed_up.code

An absolutely awesome jQuery book: http://jqueryenlightenment.com/

It's this simple: if you are a Web developer, you need this. And you will support the project. And PDF version is dirt-cheap.

Since "svn update" is a subset of "svn merge" you can use something like:

(Source: http://translocator.ws/2005/10/12/svn-update-dry-run)

The only downside is that 'svn merge' does not quite work like 'svn update' in the sense that you can not run 'svn merge' from outside the workspace. E.g. if I have several workspaces under /tmp/irakli: /tmp/irakli/one and /tmp/irakli/two, I can run:

whereas /tmp is not a workspace. We can not do the same with svn merge.

PHP error messages are quite helpful, most of the time. Sometimes they do fall short of telling us what went wrong, however. It's especially common when and if you use a development framework (e.g. Drupal). Frameworks often do output buffering and/or code eval()-ing, making debugger output incomprehensible.

In such cases PHP's debug_backtrace() function is a real savior. debug_backtrace() is also very helpful if you want to look at the execution stack in a complicated code, to better understand the code. This function shows the execution stack that lead to the current function and does it pretty well... "too well" sometimes :) Out-of-the-box version of the function shows the list of invoked functions, source files they belong to, line numbers in the source file and the argument values being passed. The latter can be a huge problem, if code is passing around large variables. Output on the screen may get so garbled (esp. if HTML is used in variables) that the entire exercise may lose its meaning.

Short snippet below sanitizes debug_backtrace() output to make it slimmer and more comprehensible:

$trace = debug_backtrace();
foreach ($trace as &$t) {
  unset($t['args']);
}
echo "<pre>".print_r ( $trace,true)."</pre>";
exit();