Simple Coding - Part 1: Return and Switch

Building code in a team environment can be challenging. Not only do you need to format code without ruffling feathers, but you need to be able to write in a manner that can be understood at a glance. Your code needs to super-obvious and intuitive.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. -- Martin Fowler

In this series, I am going to focus on coding techniques that will make your code easier to understand for the people around you. Future you will also be glad if you follow these techniques six months from now, when you have that strange bug report come in and you have to parse through code you had completely forgotten about. Just saying...

Return early, return often

When writing a function, I always try to get out of the function as quickly as possible. As soon as I have any excuse to stop execution, I get right out of there. The faster you exit a method, the less you, the reader, have to think about what's going on. Returning early has the added bonus of reducing how nested your IF/ELSE blocks become which further simplifies the code. Consider the following pieces of code:

Late return

   function lateReturn(val) {
      var retValue;
      if (val === 0) {
        retValue = '0';
      } else if (val === 1) {
        retValue = '1';
      } else if (val === 2) {
        retValue = '2';
      } else if (val === 3) {
        retValue = '3';
      } else {
        retValue = 'none of the above';
      return retValue;

Early return

    function earlyReturn(val) {
      if (val === 0) {
        return '0';
      if (val === 1) {
        return '1';
      if (val === 2) {
        return '2';
      if (val === 3) {
        return '3';
      return 'none of the above';

They both do exactly the same thing, but the late return took an extra second to mentally process. The above code samples are pretty simple, so imagine what a difference that would make in a function that takes up the screen. Your brain can move on the moment you see the return statement.

Avoid switches

I had been using switches until a few years ago when I started learning Python. When I got through learning conditions, I realized that switches were conspiciously missing. Every other language I had written in used them, so it made me consider if they were even necessary.

I worked out that my C#, Java, and JavaScript code would be better if I didn't use them at all. There are extra things to think about and the performance should be about the same. In addition, the fewer ways you have to say something, the less chance there is for miscommunication. It is better that your intent is crystal clear.

You don't want a criminal lawyer... you want a criminal lawyer -- Saul Goodman

I think Python had it right in this arena when they decided not to put switch/case statements into the language. An if/else statement when properly written can convey the same intent without forcing the user to switch into a different mental mode.

I can't tell you how many times a missing case statement or break was the source of a subtle, seemingly unsquashable bug.

Performance implications

For argument sake, I wrote up a performance comparison with 4 styles of function writing to see what the performance difference is. There is not a huge difference between the 4 styles that is consistent across browsers. Returning early and avoiding switches seems to be a pretty solid strategy for typical application/page code for all of them.