In no particular order, these are some things you should never hardcode:

1. Hostnames or IP addresses
2. Website or web service URLs
3. Email addresses
4. Database foreign keys
5. User names or user ids
6. Passwords

Usually someone hardcodes one of these things with the excuse “It’s never going to change”. What they really mean is “I’m too (choose one) :

a. lazy
b. busy
c. ignorant
d. all of the above

to make this a configurable”.

Let’s look at a few items from the list and discuss why they shouldn’t be hardcoded:

1.  Hostnames or IP addresses:  These are prone to change often as the network topology changes.  Host names change less often, but if your code references a hostname outside the sphere of your control, and your code is not throwaway, chances are a hostname you reference will change in the lifetime of your code.

One example:  your app uses a hardcoded database named okfornow.mybiz.com.  The DBA team decides build another, bigger, better server “okforalongtime.mybiz.com”. They’re going to shut down okfornow next month. “Plenty of time to upgrade,” you say, and go to work tracking down the hardcoded database name, recompiling, testing and redeploying  your code.  It will probably only take an hour or two if you’re familiar with the code.   Meanwhile the other teams that didn’t hardcode their database name just update it in the configuration, and they’re done.  It took them just a few minutes.

2.  Website or web service addresses:   These usually contain host names, so #1 applies right away.   But they also contain URL path info that might change  as the website changes its layout or the web service changes versions.

Another example (this one from real life):    Some of your production code that uses a third party web service stops working, because the web service is returning an error.   You contact support at the third party web service.  “Oh,” they say.  “We moved this web service to a new host.  We sent an email to your  company’s technical contact warning about the change a few months ago.”   Oops!  That technical contact left the company a year ago.  You rush to find where that website URL is hardcoded, change it, test it, and redeploy to production.   Your production service was affected for “only” a few hours.

3.  Email addresses:   Email addresses change.  Companies get bought, people leave, people want to replace their email address with the email of a distribution list so that other people get the email.  Plenty of reasons not to hardcode email addresses.

4.   Database foreign keys:  Typically the foreign key references a particular database entity like customer or user.  What happens when you need to use a different one?   Find, recompile, test, redeploy….

5. User names or user ids:  Just like email addresses, these things change often as personnel changes around.   Enough said.

6.  Passwords:   Passwords change often, more often than user names.  If your U.S. based company is going to be really successful and file and IPO, Sarbanes-Oxley rules may require that the development staff not know the password for a production service, which means it’s going to have to move out of the code.

So, what do you do instead of hardcoding values?  Well, there are a few choices.   Put those values in an external config file.   Put them in a database table.  You could use some sort of configuration server – something like JMX for Java springs to mind.    Just don’t hardcode them!