-6

As an intermediate stage hard-coding is accepted by Google in their Tour of Heroes Angular tutorial but the benefit cannot surely only be for novices. Do people not understand that hard-coding as an intermediate step allows an additional stage of testing to be undertaken on highly scalable systems in a manner that removes outside services from the equation and/or helps isolate individual behaviours, or is there some hereforeto unconsidered problem?

Additionally, once a dynamic solution is in place, what can be wrong with embedding these values in the code, accessible via in-code boolean toggles or environment variables, as a fall-back when troubleshooting networking issues, security problems, or isolating a bug to a single service?

Peter Carter
  • 99

3 Answers3

9

Hard coding isn't the real problem. If your problem doesn't need dynamic code then adding dynamic code isn't solving a problem.

However, problems themselves are dynamic and change over time. So it's not unusual to end up needing code to be dynamic.

The real issue is when you let knowledge spread into inappropriate places. If you think:

  • it's fine to hard code, so
  • it's fine to use a static solution, so
  • it's fine to spread references to static things to many places

well now you've now caused a problem. Because now switching to a dynamic solution is a huge pain.

The difference is subtle. Some refuse to ever work statically because it's so easy to slip. But it is knowledge, spread inappropriately, that causes the real problem. The more things that know about something the harder that something is to change. So long as a change can be made in one place hard or soft doesn't really matter.

As for testing. Just don't add it late. Putting off testing makes it more expensive and less useful. If you can test early and be static fine. For most though that's easier with dynamic solutions.

Dynamic solutions can solve static problems. Problems can become dynamic. A dynamic solution can make testing easier. But you don't get dynamic for free. It's work. Don't trust anyone that insists there is only one way. Find out for yourself what either will cost you.

candied_orange
  • 119,268
6

Hard coding should be reserved for invariants.

If you know that some data is very unlikely to change, you hard-code it.

const int numberOfStandardChessBoardSquares = 64;

For everything else, there's configurations.

There are compelling reasons to hard-code things. You would not compute Pi each time you need it, because that computation is expensive. Rather, you decide what resolution you want, and code a constant:

const double pi == 3.1415926535897;

If you stand up a complex system that requires some kind of diagnostic mode, it can be handy to have some sort of data pattern hard-coded into the production code so that you can transmit data across your system with a known fingerprint. You don't want this kind of data in a configuration file that's subject to tampering, and in the unlikely event that the baseline data pattern needs to be changed, one would simply deploy a new production version.

In the absence of the need for such a diagnostic mode, test data of this kind is better kept in a test harness or test assembly, where it can be cut away from the production executables prior to deployment.

Community
  • 1
Robert Harvey
  • 200,592
2

Do people not understand that hard-coding as an intermediate step allows an additional stage of testing to be undertaken on highly scalable systems in a manner that removes outside services from the equation and/or helps isolate individual behaviours, or is there some hereforeto unconsidered problem?

What?

No, hard coding is a code smell, full stop.

If anything, doing so in microservices is extra troublesome because microservices will tend to need more configurability because

  1. There's rarely ever one instance. Hard coding to one instance will fail once you have two instances/targets/databases/whatever.
  2. There's rarely ever one locale. As soon as you hardcode strings/timezones, things will break once you deploy to that other region.
  3. There's rarely ever one host. Containers can kinda mitigate this, but as soon as you hardcode some file path or make assumptions about your OS, it'll fail when you switch containers or web servers or OSes or...

But like all code smells - sometimes you follow the smell and end up somewhere that isn't terrible. Sometimes a simple hardcoded value has very little downside. Sometimes it can provide something that can't possibly go wrong. Sometimes it's in a spot that would need to be destroyed entirely if the assumption of the hard-coded value changes.

Though usually it's just people being lazy.

Telastyn
  • 110,259