Monthly Archives: May 2013
So had an interesting experience today, where I had to maintain some code someone else has written. It’s not important what the code did, however it was written in some very very clever C, but had next to no documentation.
So what do we do when we’re faced with that situation?
Well I was fortunate that the developer who wrote it still worked where I work. But rather than take the easy option and pinging him an e-mail going “what were you thinking when you wrote this?” I decided to have a crack at it myself. So I checked out the code to my own work area and got to work, adding comments for all the stuff I’d managed to work out.
There were some things I just couldn’t figure out, as I’d not come across them before. So I put down what I *thought* that code did. But the cool thing was once I’d done that, I decided that I could now ask the developer about their code, so I sent him a copy of the code with my comments in it, and got his feedback. I was way out in some things, pretty close on others, which was pretty neat.
So lessons learned:
- Sometimes, we’ve got to deal with code that isn’t ours. Therefore it’s moved me to make sure I document my code, because at some point someone’s going to come after me to try and make sense of what the heck I’ve done.
- When you’re faced with someone else’s code, and they still work at the company, have a stab at working it out for yourself first. My first temptation was to e-mail the guy straight away, but then I’d learn nothing, and the guy would be rightly pissed off with me for not making an effort.
- It may be all well and good to be clever and do something on one line, but for the sake of the future developers, if there’s a simple way to write it, then do it that way. It may increase the line count by one or two lines, but future developers will thank you for it.
- You can learn a lot by reading other people’s code too 🙂