What's the point in hard coding values which may change?

Question

Hi,

When coding systems which use configuration information, it is always a best practice to soft code these on some medium like Xml so these values can be edited without recompiling the entire system.

However, plenty of values like Urls are hard coded and these can change. What's the benefit in coding this way? This obviously reduces flexibility.

EDIT: I know the answers seem simple, but I see this practice so many times that it feels as if I am missing something.

Thanks

Answer 1

Lazy programmers, or they don't expect values like URIs to change anytime soon. It's also possible that they don't want to take the time to implement an XML parsing and saving system for the sake of convenience, but that ties into laziness.

Answer 2

Although this is a subjective question, most of the rationale of "hard coding" is so that it is more difficult for a user to change or see the option.

For example, if I were playing with your proprietary media player, and I came across this:

[RuntimeOptions]
    ServiceURI=https://mycompany.com:10249/z/ax.php?f=%s&a=%s

It's obvious you don't want me knowing what that does. I'd be inclined to modify it and say:

[RuntimeOptions]
    ServiceURI=https://devbox.jedsmith.org/test.php?firstarg=%s&secondarg=%s

To see what your application is requesting at runtime. Hardcoding the value into the executable makes it more difficult but not impossible to still get at and change the value. strings is your best friend, here.

Note that I've given a specific example, here, and this isn't necessarily the only reason -- just one.

Also, hard coding does not necessarily imply forgoing XML; in fact, the property list format that Cocoa development is fond of allows "hard coding" constants into the application using XML at build time. Not all that goes into an executable is code.

Answer 3

There are no benefits in enterprise environment where every application has access to centralized configuration store. Matter of fact, our company has a code validation rule (e.g. you can not check in/release code that violates it) that prohibits hard coding URLs without waiver from central Engineering team.

Outside corporate environment, I must agree that the main plausible benefit is obscurity from the user; or control (as alluded to by Jed) if there are some serious problems with using different URL.

Answer 4

One "benefit" I can think of is being able to rely on the value (URL) always being there. Configuration files can be edited or deleted (sometimes by accident). If the URL is crucial to the program, and changes infrequently (say, every release), I think it's reasonable to hardcode it -- in this case, having it in a configuration file won't buy you much.

Answer 5

Could reducing flexibility have an advantage? Sure, there are a few that come to mind:

1. The makers of the system do not want there to be so much that can be configured or believe that giving too much flexibility may bring headaches.
2. There is a speed advantage to doing this as making the value go into a config file does take a few seconds as well as coming up with a naming convention.
3. If there are already dozens of values in a config file, it may not be so good to add another one to a file of hundreds of URLs, just as a thought.

There are almost always reasons for doing things one way or another. In some cases it may not be easy to see why that is so, thus you have to look for the "Yes."

Answer 6

KISS - hardcoding is the simplest solution that works, so it is preferable unless you have concrete reasons not to do it.

it is always a best practice to soft code these on some medium like Xml so these values can be edited without recompiling the entire system.

I disagree, unless where you actually want the end user to be able to change those values. If recompiling/redeploying is something so terrible you organize your code to avoid it, the problem is not the code, it is your build process.

Such "soft coding" actually makes your system less reliable, as you now have a parsing component that can fail, a file format that needs to be validated (and validation errors handled in some useful way) and learned by developers. Changes in configuration files need to be tested just like changes in source files, but often aren't.

Answer 7

There is a lot of talk here that implies that hard-coding values is the practice of the lazy or inexperienced programmer, which I find to be nonsense. One benefit that immediately springs to my mind is that of sheer simplicity.

If you have a small number of "configuration" values in your software, having some separate XML config file maybe just a little over the top for your needs. I think the crux of the matter is that you have to decide what benefits some sort of external config description will bring to the software, for example, manageability or the ability to change the configuration without recompilation (by developers or end users) etc... If there is no real good reason for doing so, then you may be better off not doing it. If you reach this decision, that does not make you lazy or inexperienced.

Answer 8

We all know that primitive values like Strings are less-safe than richer types. More mistakes are possible, so you might have to add many additional tests, or live with a non-robust system.

This is one case where you can't have everything, you have to choose (this is 'architecture' then :-) ).

In a previous project, our architecture was to avoid primitive types when possible. We employed many enums (java5) to type them strictly, along with providing additional information as needed, and so on.

For your URL example, each of our modules could provide an Module1Url enum, with all the instances pointing toward specific urls. Other concerns would have other types of enums.

We gained:

• compile-time checking : provides completion that makes us more productive, instant error-detection that made that many JUnit tests unnecessary.
• duplication of constants was reduced to zero (we had no two enum classes named alike)
• evolutivity : in the rare cases where we needed configurability on-site after the fact, it was so easy to externalize (only for that case). Only the enum code would be modified to look up the value in a property file, all other codes would still ask the enum for it.
  And all such enums could be grouped in a JUnit test suite, so we would gain build-time and run-time verifications that none of our property files would have a single missing or misspelled value.