Out of ideas? Not out of things to do (to improve your code)!

This will seem like the most obvious tip ever, but I thought I’d get it out there for those that may have forgotten about it in a while. If you’ve ran out of ideas on what to work on  your project next (i.e. you have no new features or improvements in mind), try going through your codebase and find the oldest pieces of it. (Side note: Having your codebase be in something like a Git repository that can tell you when each line of code was committed and thus last edited can be amazingly helpful.) Chances are you’ve grown since then. You’re a better developer. You have more tricks up your sleeve. Maybe you know of a new algorithm, a new library, a new, better way to do things. Maybe you’ve read about security risks you weren’t aware of. There’s almost definitely going to be something there that could use some tidying up, some improvement.

Look for redundancies, variables or parameters that seemed helpful at the time, but now seem obviously unneeded. Look for opportunities to refactor, to optimize, to parallelize. Look for possible security risks, replace unsafe procedures and methods with safer ones. Maybe try doing a whole piece of code from scratch.

During one of my interviews, one of the tests I was given was to correct the problems in a piece of code that shuffled a deck of cards. The procedure used to do that was so blatantly unoptimized both as far as space and time goes, that I rushed out of the office to find my examiner and ask if I could just rewrite the whole thing. I was told that I would get “bonus points” for writing my own approach to the problem, but I had to consider that maybe I could not do such drastic changes to the code, and had to just correct the code, without affecting the algorithm itself.

Which brings me to a couple of last notes:

– Old code will probably have both incoming and outgoing dependencies that aren’t immediately obvious. Just because the code compiles after your changes, doesn’t mean that everything works as it should. Maybe other parts of your code depended on how things were done before you rewrote the whole thing. So, the bigger the change you make, the more rigorous the testing needs to be afterwards. Keep that always in mind. A program that compiles right isn’t necessarily one that works right.

– Sometimes it’s better, or even required, that you don’t mess with the code too much. You can try to improve things by making slight changes, fixing bugs and doing small optimizations, but rewriting the whole way it works may end up breaking more things than you’re willing/have the time/have the knowledge to fix. So, even though rewriting the whole thing might seem the obvious first choice, think about whether the space and time improvements are worth the complexity of making sure to test everything afterwards. The more rewriting you do on one part of the codebase, the more rewriting you may end up needing to do in other parts of the program to make it compatible with the new way things are done. And that might lead to an “avalanche effect” of changes needed to be done throughout the codebase, at which point you’ll have already regretted applying your bright idea to that old piece of junk.

– Do not fix things by trying to force the program to compile. I remember that my approach to pointers at some point during my first or second year of University was so naive, that I would be adding “&”s and “*”s to function signatures and callers until it “just worked” or “just compiled” apparently correctly, key word being “apparently”. Understand what the compiler means by that error, and take a long hard look at why that piece of code is failing at compile-time. Compile-time errors are the easiest ones to fix. No stack traces to walk through, no crashes with no meaningful error to help either the user or you, just a simple filename and line indication that tells you that that piece of code logic is faulty. So, break it down, and try to fix it. Maybe the error isn’t even right on that line, maybe you’ve made a mistake some way above and that line is merely the trigger of the compiler error. So, correct your errors with as much care as you would write the code the first time. The last line of the first note still stands, “a program that compiles right isn’t necessarily one that works right.

Advertisements

4 thoughts on “Out of ideas? Not out of things to do (to improve your code)!

  1. When I rewrite a function, if possible I will write some very conservative unit tests for the function and then try and rewrite it. Probably doesn’t work for every situation but I think it is a good habit.

    • That’s a good idea to make sure you don’t break things that should be producing certain results in the function, however that may not take into consideration assumptions that were made when other parts of the code were written, assumptions based on the way the function was written initially. If you’re sure that all other parts of the program only depend on the result, and not the means to get to it, unit testing may prove to be sufficient.

      In general, if you’re well-aware of all the dependencies the code has, all the variables and data it edits that may later by accessed by other parts of the code, and write unit tests for all of those, you might be safe. But then again, writing proper unit tests could be a challenge of its own, depending on the kind of data and the work that’s being done to it.

      When all is said and done, any rewrite is risky business. In all cases, the optimal way as far as errors go (although far from optimal as far as time goes (again, the time you may need to spend if things go wrong not taken into account)), is to rewrite slowly, doing rigorous testing (unit tests or otherwise) of every rewrite, to make sure you haven’t broken something. Doing rigorous testing on complete rewrites can be the biggest challenge of all, from what my experience tells me.

      • That’s a good point, I was only really thinking about when I rewrite a small static function for better performance (My heads still a bit in the code). I can imagine having heaps of different states would make it very hard. I think many a times, looking over old code I see a line and think to myself “That shouldn’t be here, it does nothing” I remove it and my program stops haha.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s