Soft Coding
Over at Worse Than Failure, Alex Papadimoulis has an article on soft coding. Hardcoding is when something is written in the code when it ought to be in a header constant or an external config file. Soft coding is the opposite, when something is put in a config file that really ought to be in the source. For instance, the number of days in a week isn’t likely to change any time soon, so you may as well just use “7” in your code. You might
#define DAYS_PER_WEEK 7 #define WEEKS_PER_YEAR 52 #define LOAN_DURATION DAYS_PER_WEEK * WEEKS_PER_YEAR
to make it clear what you’re calculating, but putting it in an external, user-configurable file is just absurd.
I’m guilty of softcoding, myself. In my experience, it comes from trying to be too generic. Code that’s too specific, too hardcoded, is hard to maintain and extend, so a good programmer will ask himself, “What requirements might change in the future? How should I write this so that when it changes, I can do it without too much pain?” This leads to things like declaring configuration constants at the top of a script, in a Makefile, or in a header file; or having the code read messages from an external file, rather than hardcoding them as strings.
But it’s also easy to overcompensate, and start making everything customizable, or overly generic. So it’s important to remember that at some point you have to actually make the code do something.
