Are there advantages to hard-coding data values into a program?

Question

I'm a self-taught, novice-ish coder, so I apologize if I don't nail the programmer lingo.

I'm working on a project in which I am providing data, which will be continually updated, to developers who will essentially create a tool to generate reports from queries on the data.

It seems that everyone involved thinks that they need to hard-code data values (not the schema, but the domains/values themselves) into the report-generation program.

For example, suppose we were reporting on personnel; the report would be split into categories, with a heading for each department, and then under each department heading will be subheadings of job titles, and then under each subheading will be a list of employees. The developers want to hard-code the departments and job titles. On the other hand, I would think that they could/would query out those things at runtime, sort records by them, and generate report headers dynamically based on what values are there.

Since the list of potential values will change over time (e.g., departments will be created/renamed, new job titles will be added), the code will need to be continually updated. It seems to me that we could skip the code maintenance steps and dynamically organize the reports.

Since I am not a developer, I'm wondering what I'm missing. What advantages might there be to hard-coding values into a tool like this? Is this typically how programs are designed?

Answer 1

Really? No Possible Valid Use Cases?

While I agree that hard-coding is generally an anti-pattern or at least a very bad code smell, there are plenty of cases where it makes sense. Here are a few.

• Simplicity / YAGNI.

• Real constants that actually never change.

  ie the constant represents a natural or business constant, or an approximation of one. (e.g. 0, PI, ...)

• Hardware or software environmental constraints

  In embedded software, memory and allocation constraints come to mind.

• Secure software

  These values are not the be available and/or easy to decode or reverse-engineer, e.g. cryptographic tokens and salts. (Note that keeping them hard-coded does have obvious downsides as well...)

• Generated code

  Your preprocessor or generator is configurable, but spits out code with hard-coded values. Not unusual for code that relies on rule engines, or if you have a model-driven architecture.

• High-performance code

  In a way this is "generated" code, although even more specialized. e.g. a pre-determined lookup/computation table with unlikely changes. This isn't unusual at all in graphics programming for instance.

• Configuration and Fallbacks

  Both in your actual code and in your configuration files, your are likely to have configuration values, and fallbacks for several cases (when the configuration is unavailable, when a component doesn't respond as expected, etc...). Still, it's generally best to keep it outside of your code and look it up, but there might be cases where you absolutely want to have a specific value/reaction to a specific action/issue/situation.

• And probably a few more...

Still an Anti-Pattern? So is Over-Engineering! It's about your Software's Life Expectancy!!

Not that I'm saying there are all great reasons, and generally I'd balk at hard-coded values. But some can easily get a pass for valid reasons.

And don't oversee the first one regarding simplicity/YAGNI either by thinking it's trivial: there's probably no reason to implement a crazy parser and value checker for a simple script that does one job for a narrow use case very well.

It's difficult to find the balance. Sometimes you don't foresee that a software will get to grow and last longer than the simple script it started as. Oftentimes though, it's the other way around: we over-engineer things, and a project gets shelved faster than you can read the Pragmatic Programmer. You wasted time and effort on things than an early prototype did not need.

That's the mean things with Anti-Patterns: they're present in both extremes of the spectrum, and their appearance depends on the sensitivity of the person reviewing your code.

---

Personally, I would tend to always go the generic route, as soon as I see that something might change or if I've had to do it more than once. But a more precise approach would be to evaluate carefully the cost of hard-coding vs generating or generifying your code for that specific situation. It's the same as determining if a task is worth automating as opposed to doing it manually. Just take into consideration time and cost.

Answer 2

Wikipedia:

Hard coding (also hard-coding or hardcoding) refers to the software development practice of embedding what may, perhaps only in retrospect, be considered an input or configuration data directly into the source code of a program or other executable object, or fixed formatting of the data, instead of obtaining that data from external sources or generating data or formatting in the program itself with the given input.

Hard-coding is considered an antipattern.

Considered an anti-pattern, hard coding requires the program's source code to be changed any time the input data or desired format changes, when it might be more convenient to the end user to change the detail by some means outside the program.

Sometimes you cannot avoid it but it should be temporary.

Hard coding is often required. Programmers may not have a dynamic user interface solution for the end user worked out but must still deliver the feature or release the program. This is usually temporary but does resolve, in a short term sense, the pressure to deliver the code. Later, softcoding is done to allow a user to pass on parameters that give the end user a way to modify the results or outcome.

• Hardcoding of messages makes it hard to internationalize a program.
• Hardcoding paths make it hard to adapt to another location.

The only advantage of hardcoding seems to be fast deliver of code.

Answer 3

There are times it's OK to hard-code values. For example, there are some numbers like 0, or one or various n^2-1 values for bitmasks that need to be certain values for algorithmic purposes. Allowing such values to the configurable has no value and only opens up the possibility of issues. In other words, if changing a value would only break things, it should probably be hardcoded.

In the example you gave, I don't see where hard-coding would be useful. Everything you mention would/should already be in the database including headings. Even things that drive the presentation (such as sort order) can be added if they aren't there.

Answer 4

Implementing a robust solution that allows for values that might otherwise have been hard-coded to instead be configurable by the end users demands robust validation of those values. Did they put in an empty string? Did they put in something non-numeric where it should have been a number? Are they doing SQL injection? Etc.

Hard-coding avoids a lot of these risks.

Which isn't to say that hard-coding is always, or even often, a good idea. This is just one of the factors to take into account.