Is hard-coding literals ever acceptable?

Question

The code base I'm currently working on is littered with hard-coded values.

I view all hard coded values as a code smell and I try to eliminate them where possible...however there are some cases that I am unsure about.

Here are two examples that I can think of that make me wonder what the best practice is:

1. MyTextBox.Text = someCondition ? "Yes" : "No"
2. double myPercentage = myValue / 100;

In the first case, is the best thing to do to create a class that allows me to do MyHelper.Yes and MyHelper.No or perhaps something similar in a config file (though it isn't likely to change and who knows if there might ever be a case where its usage would be case sensitive).

In the second case, finding a percentage by dividing by 100 isn't likely to ever change unless the laws of mathematics change...but I still wonder if there is a better way.

Can anyone suggest an appropriate way to deal with this sort of hard coding? And can anyone think of any places where hard coding is an acceptable practice?

Answer 1

The real question isn't about hard coding, but rather repetition. If you take the excellent advice found in "The Pragmatic Programmer", simply Don't Repeat Yourself (DRY).

Taking the principle of DRY, it is fine to hardcode something at any point. However, once you use that particular value again, refactor so this value is only hardcoded once.

Answer 2

And can anyone think of any places where hard coding is an acceptable practice?

• Small apps
• Single man projects
• Throw aways
• Short living projects

For short anything that won't be maintained by others.

_{Gee I've just realized how much being maintainer coder hurt me in the past :)}