Recently I’ve been working on a medium sized php-based web site. The code is written in php, and clearly not by someone experienced in the black art of readable code. I never really considered it before, but it just occurred to me that side effects (eg. changes to global state) in library files are just utter crap. Anyone writing code based on such foul practices really should not be allowed near an editor ever again.

Let me explain.

Imagine including functions.php from the file index.php. functions.php in turn includes functions1.php and functions2.php. These of course may include even more library files ad nauseum. One of these files sets the variable $obscure_result. Not only that, but a few other files (also included) modify the value of $obscure_result based on some criteria.
Now, assume that $obscure_result turns out be wrong, or it needs to be calculated in another way. First, attempting to even determine where $obscure_result gets modified is a pain, since it requires an analysis of which files actually get (recursively) included. Additionally, each of these files must be checked to see if their changes to $obscure_result depend on some other bit of state (which in turn may also be a global variable modified throughout various included library files). All in all, side effects in library files are a nightmare, and should be avoided, lest you are into pain and suffering.

A while back I started a new job at Marimatech. The job as well as the colleagues there are excellent, and it has given me an opportunity to brush up on my somewhat rusty C++ skills, as we are rewriting a rather large protocol stack more or less from scratch. I never actually took the time before, to write anything of a reasonable size in C++, so actually doing that has taught me a great many things.

Love your debugger.

In this case that means gdb, which is incredibly powerful, but has a somewhat steep learning curve. Once you master the basics, however, fixing segfaults and logical errors becomes much simpler then with the printf() (or cout) method which has worked so well in the past. Debug and error logging is still incredibly useful, but running programs in gdb makes lots of errors trivial to find.

Love your profiler

In this case that means valgrind. Like gdb it is extremely powerful, and comes with tools for profiling as well as for detecting memory leaks. Having never really needed a profiler before, I am thoroughly impressed. Of course kCacheGrind makes working with valgrind sweeter still, almost to the point of being too easy.

Long story short, C++ is starting to grow on me. I am pretty sure that writing in C++ once in a while improves my programming skills with respect to other languages as well.