Is this Smart Code or Cute Code or just Code that will Break Someday ?!?

Consider the following chunk of JavaScript code:

Look like perfectly good code, doesn’t it ?

And this is the code one unnamed senior software engineer at one fortune 500 company told me recently to write.  He just wanted to see fast codes.

But where might this code break. if it were to break ?

Code Chunk #1

Each of these red arrows tells us where this code might break because each of these red arrows highlights an assumption that could be false just as easily as it could be true.

If you wanted this rather simple-looking JavaScript function to execute without failures it would look like this:

Code Chunk #2

In this second chunk of code we have the same functionality as the first chunk of code with a possible performance loss of something like 0.01% per 10 million iterations or negligible performance cost but ALL of the previous assumptions have been handled and accounted for.

Which code is better for your needs ?  The hastily written code that has 3 assumptions that could fail OR the carefully crafted code with fewer points of failures.

In all fairness the guy who directed me to write the code that could fail works for a major publicly traded company that is known to have a lot of code defects to worry about – something like 800 defects that had to be knocked down to something like 200 defects in about 4 months time.

What is the cause of their defects ?   Hastily written code, maybe ?

Sure it seems like the hastily written code with fewer lines to think about might run faster and it might run 0.01% faster if there were 10 million iterations however the cost if that hastily written code breaks would be far greater than if the more carefully crafted code had been written in the first place.

Why didn’t that senior software engineer like the more carefully crafted code ?   He has probably never given how he writes code a second thought let alone a first thought and he has probably been writing code that way his entire career – never trying to figure-out why his code ever fails… but since he works with so many people he probably never gets an opportunity to see why his code might break and he can always blame code failures on something or someone else without ever having to take personal responsibility for his coding style.

Why does this major fortune 500 company have so many code defects to deal with ?

Take another look at the code I was directed to write and take another look at the code that would fail in a safe manner and then you decide which function would last longer when variables change or the business changes or the design changes.

I have worked with more than a few programmers who think, because they lack sufficient experience, that certain variables cannot change.  I have also worked with those who feel web servers never go down.

In my experience variables do change and code can fail unless one takes a bit of care to ensure the code being written is fail-safe.

Is performance a legitimate reason to write code that may fail at some point ?

NO !

If calling functions and performing Boolean Logic is the source or some kind of performance issue then by all means stay in bed and pull the covers over your head because there is no hope for you, if you feel like this would-be senior software engineer was the least bit right in what was said.

Modern JavaScript is quite capable of performing single instance function calls as well as simple Boolean Logic statements without the need to be the least bit concerned about performance assuming performance was the primary goal.

Consider the following chunk of code again:

Code Chunk #3

Here we have everything on a single line of code, looks more concise than Code Chunk #2 but Code Chunk #3 also handles all 3 points of failure that came from Code Chunk #1.  For all I know the guy who did not like Code Chunk #2 may have been thinking of Code Chunk #3 but I doubt it based on how he used his words about performance and brevity, etc, and I have not been seeing code that looks like Code Chunk #3 is the body of code I have been looking at for this company.  I have been seeing a lot of code that looks like Code Chunk #2 and I can easily understand why this company has been dealing with so many quality issues.

Also in all fairness, the senior software engineer who told me he did not like Code Chunk #2 has been dealing with a great number of code defects during the past 4 months and has probably always been doing this for this same company and he is probably not allowed to ever get any time to reflect on anything related to his coding style or how he might make improvements to his coding style – he always might feel offended if he felt his coding style could be improved since he has some rather strongly held feelings about what looks like good code to him.

The moral of this tale, if you choose to believe any of it is…  with a little time and some reflection you too can learn to write more robust code that will stand the test of time and more than likely you would be helping the company you work for to enjoy greater profits by reducing their software maintenance burden while boosting the acceptance of their software among their user community.


You can just ignore everything that was said here and continue writing code the way you have always been doing because your code seems to run faster or you just love to look at code that seems more concise or whatever the reasons…  but if you worked for a company that had you on a treadmill fixing a ton of software defects you might someday learn how to write more robust code…   In a world where most people want to ignore global warming those same people might want to ignore what might be more robust code.

I choose to write more robust code whenever I can because it saves me time and money in the future and I get my projects done faster when I do this. Believe it or not !


About Ray C Horn
See my profile at with more than 1286+ connections and growing all the time.

2 Responses to Is this Smart Code or Cute Code or just Code that will Break Someday ?!?

  1. xeon2k says:

    Nice blog.. But just a question here. Is it fine if we know for sure that object can not be null in any scenario and continue writing concise code?

    • raychorn says:

      You can know anything you wish to know and your code can assume what you know is true however whenever your assumption(s) prove to be incorrect you will have bugs. Additionally concise code need not make any assumptions that could prove false. While you may feel your code will execute faster when it is as concise as possible it is also true that boolean expressions execute very quickly – for JavaScript a boolean expression will consume something like 0.01% for 10 million iterations which is hardly measurable; you would have to code a whole lot of boolean operations to cause a measurable drop in performance. You might try doing some benchmarking before you go thinking concise assumption filled code actually runs faster than the other kind that may appear to be less concise with fewer assumptions. Just something to think about…

%d bloggers like this: