It isn’t Hard to Hard-code!

Posted: April 3rd, 2014 | Author: | 3 Comments »

Recently I came across an interesting programming situation.

Parts of a web-based system stopped working suddenly, with nothing significant having changed. After some finger-pointing and accusatory guessing, it was discovered that some scripts on server side had been shifted from /root/1level to a deeper nested folder, let’s say /root/1level/2level. So far so good.

What happened next? Why would that make a system stop working?

Code needed to find path for some processing. The code split on first backslash to find file name, implicitly assuming that the file would always be one-level deep from root. When the file was shifted into a deeper folder, the path extraction stopped working.

There can be arguments about whether the admin should have shifted files into a deeper folder without informing developer, or why this should not have been done at all, and so on. But I consider this a clear elementary programming mistake of the hard-coding variety.

Hard-coding does not mean just typing in numeric or string literals into code, although that is the obvious college-level hard-coding. X = 420 or sEndDate = “1/1/2022″. It also means any type of inflexibility embedded right into the code and program. Hard-coding means not understanding the need for flexibility and not writing elegant code that can adapt to its surroundings.

Hard-coding is called “hard” coding because anything hard cannot be molded to suit the need at hand, because it is inflexible. Like when you put in an assumption that your file is one-level deep,, which makes it inflexible to run when its level changes.

What would be the right way to deal with this?

Step 1: extract path in a loop, so that you can handle any level of folder-nesting. You don’t assume you are N levels deep, because folder-level is not something that can be assumed! Instead you traverse the path to find how deep you are.

Step 2: Back-slash? Welcome to multiple OSs! The file-separator character itself is hard-coding. In every language worth its salt that runs on multiple OSs, you have operators to find environment variables including file-path separators. On Unix/Linux you are “/”, on Windows you are “\” or “/”. On Mac you had “:” long back during MacOS, and now you have “/” on OS X with its Unix core. And then I was on some Solaris/RISC machines decades back which used “.”.

Should you hard-code assumptions about N-level nesting and separators? Absolutely not.

Does it need extra time to write flexible code? Absolutely not. The amount of time you spend later in not writing tight right code in the first place, so much of debugging and frustration and rework – it would all be avoided if it were first-time right. And to write above path-extraction code in a loop with separator detection rather than hard-coding – you are talking about couple extra minutes. Take one less leak and you can find time to do the right thing!

Is it rocket science that an average programmer cannot do? Absolutely not. Once you decide to do things like this, it is pretty easy actually.

Then why do people not do it?

Because of mediocrity. A mediocre mind is happy with sub-standard work that somehow passes through. Because of lack of involvement. When you are pushed into a “career”, you are least concerned with your quality of work. As long as the next raise comes around, who cares! You are not a craftsperson to take pride in work, you are just a code jockey.

This, ladies and gentlemen, is the difference between a good software engineer and someone who just gets things to work. A good software engineer anticipates need for change and does things first-time right. A good software engineer thinks ahead and does things in flow during first-code which take very little additional time to do. A good software engineer does not hard-code, either directly as literals or indirectly as implicit assumptions.

Someone who is just a programmer does not do any of the above, and just somehow gets things to work – never sure when it will fall apart.

Now you decide what you want to do.

 


Posted in Software Engineering, Software Quality, Thoughts | Tagged , , , ,
  • Abhijit Panda

    I remember having faced a similar problem when I started coding as a fresher(10 years back) and that time I wondered why it did not come to my mind in the time of coding… I guess most of the time, we deal with a lot of really difficult stuff, but forget to apply the common sense :)

  • Well Wisher

    This is really an interesting article, I have few questions for the author:

    1. Why can’t we keep path of a file in a setting file or like that ?

    2. If Admin have rights to move the code file anywhere then again you will ask Admin has rights to delete settings file of your application and it must work.

    I think Admin have right to change the settings not to delete or replace a file.

    3. Regarding coding standard:

    If a developer will work contineously 60 days, 15days of contineous night out without any break, I don’t think at that time you have any rights to question on coding standard.

    4. Always commentatoring outside of field is lot more easier than batting/fielding/bolwing in field.

    I think you got your answer.

    • Chinmoy Panda

      Dear Well Wisher, thanks for your thoughts.

      I don’t agree with your “setting file” solution. You CAN keep path in setting file but you don’t know where the file’s root folder will be in relation to system-root. It depends on where the file’s root-folder has been placed in file-system – root vs rootmyfolder1myfolder2 as example. Keeping in setting file means that every time the file-hierarchy is moved from one location to another, the setting file has to be MANUALLY updated, just like in this situation code had to be MANUALLY updated. A setting file externalizes the hard-coding from code to another file, but what if good-coding can insulate code from effect of change in file location, what if good-coding can make such implicit hard-coding unnecessary – that is the question addressed in this post.

      Regarding coding standards, one never sees points like the one mentioned in this post as part of “coding standards”. This comes from a simple desire to do good work, and the intuitive ability to recognize what good-code vs time-required mean!

      You expressed frustration about 60 days, 15 continuous nights. I hear you. And is that the case here? Is it lack of time or lack of understanding, knowledge, desire to do good work? The changed code takes few minutes to write now. If not done, it adds few days of rework and frustration later, adding burden to an already overworked developer. Do the math.

      Finally, as a hardcore programmer and software developer myself – something that you may not be aware of – I really bat, bowl and play right in the same field as the topic I wrote about.

      Anyone can play. The question in this post is – how well do we play?

      Thank you for your comments, cheers :)

iso 9001 QA25 Nasscom Red Herring zinnov STPI iso 27001

copyright (c) Mindfire Solutions 2007-2013. Login