Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Is it ever a good idea to hardcode values into our applications? Or is it always the right thing to call these types of values dynamically in case they need to change?

share|improve this question
2  
a config parameter would help you –  Tech Jerk Apr 14 '11 at 4:44
32  
You never know when the value of pi might change... –  Gabe Apr 14 '11 at 4:46
7  
Man, I guess people like @gabe are the reason this is a "Rule". If you repeat 3.14 in 20 places in your code and then find that you actually need more accuracy, you are screwed. I didn't realize this wasn't obvious. –  Bill K Apr 14 '11 at 6:05
7  
That was a little rude, @Bill. @Gabe was clearly joking, but aside from that, the question was about hardcoding vs. config parameters, not using a constant vs. repeat magic numbers in multiple places. –  David Conrad Apr 14 '11 at 12:45
1  
Yes, hardcoding can be a good idea sometimes. See the Wikipedia article on the "Softcoding" anti-pattern. –  user16764 Apr 14 '11 at 13:51

15 Answers 15

up vote 49 down vote accepted

Yes, but do make it obvious.

Do:

  • use constants
  • use a descriptive variable name

Don't:

share|improve this answer
3  
You'll end up using a comment anyway, so a constant or variable with a descriptive name doesn't take any more effort. –  JeffO Apr 14 '11 at 2:42
28  
Which is cleaner, diameter = 2 * radius or diameter = RADIUS_TO_DIAMETER_FACTOR * radius? There indeed are corner cases where a magic number may be better solution. –  Joonas Pulakka Apr 14 '11 at 5:57
2  
I can't agree with this answer enough. I tend to think of programming like being a novelist. You tell your story through the code and if people cannot understand the logic it makes your code worthless in my opinion. That's why well thought out naming conventions are essentially for readability. Also, there is no good reason to use magic numbers. By using magic numbers you remove the "why" from the equation and make it more difficult to understand. For instance: "diameter = 2 * radius" What is the two for? This "diameter = RADIUS_TO_DIAMETER_FACTOR * radius" makes much more sense. –  chrisw Apr 14 '11 at 12:29
4  
diameter = 2 * radius is straight from high school maths. The reason for not naming the "2" is that for it to have a value of anything else would require a change to the laws of physics or maths, or both. (On the other hand, naming Pi, or Plancks constant is a good move for simple readability). –  quickly_now Apr 14 '11 at 13:32
4  
@Joonas: Pfft. Surely you mean diameter = radius << 1? I suppose that could also be diameter = radius << RADIUS_TO_DIAMETER_BITS_TO_SHIFT. –  Ant Apr 14 '11 at 14:14

As an addition to other answers. Use constants for strings when possible. Of course, you don't want to have

const string server_var="server_var";

but you should have

const string MySelectQuery="select * from mytable;";

(assuming you actually have a query where you want to get all the results from a specific table, always)

Other than that, use constants for any number other than 0 (usually). If you need a permission bitmask of 255, don't use

const int 8th_bit=255; //or some other obscure naming scheme that equates to 255.

instead use

const int AllowGlobalRead=255;

Of course, along with constants, know when to use enumerators. The above case would probably fit well in one.

share|improve this answer
    
typedef enum {state_0 = 0, state_1 = 1, state_2 = 2, ...}... Don't laugh, I've seen it done. Smack that person around the head with a wet fish! –  quickly_now Apr 14 '11 at 3:04
    
@quickly well of course you'd want something more like typedef enum {init_state=0, parse_state=1, evaluation_state=2, ... } –  Earlz Apr 14 '11 at 3:10
4  
THIS_NAMING_CONVENTION_IS_RECOMMENDED_FOR_CONSTANTS –  StuperUser Apr 14 '11 at 12:20
3  
For strings, you don't just want constants. You want to put any user-visible strings into some sort of resource file (details will depend on your platform) so you can change to another language easily. –  David Thornley Apr 14 '11 at 13:45
    
You might also want to stick business-logic-related strings (like SQL queries) in a resource file with some kind of encryption or obfuscation. That will prevent "curious" users from reverse-engineering your logic (or database schema). –  TMN Apr 14 '11 at 15:09

What I find odd about this Q&A so far is that nobody has actually attempted to clearly define "hard-code" or, more importantly, the alternatives.

tl;dr: Yes, it is sometimes a good idea to hard-code values, but there's no simple rule as to when; it depends completely on context.

The question does narrow it down to values, which I take to mean magic numbers, but the answer to whether or not they're a good idea is relative to what they're actually used for!

Several examples of "hard-coded" values are:

  • Configuration values

    I cringe whenever I see statements like command.Timeout = 600. Why 600? Who decided that? Was it timing out before, and someone raised the timeout as a hack instead of fixing the underlying performance issue? Or is it actually some known and documented expectation for processing time?

    These shouldn't be magic numbers or constants, they should be externalized in a configuration file or database somewhere with a meaningful name, because their optimal value is determined largely or entirely by the environment that the application is running in.

  • Mathematical formulas

    Formulas usually tend to be pretty static, such that the nature of the constant values inside isn't really particularly important. The volume of a pyramid is (1/3)b*h. Do we care where the 1 or 3 came from? Not really. A previous commenter rightly pointed out that diameter = radius * 2 is probably better than diameter = radius * RADIUS_TO_DIAMETER_CONVERSION_FACTOR - but that is a false dichotomy.

    What you should be doing for this type of scenario is creating a function. I don't need to know how you came up with the formula but I still need to know what it's for. If, instead of any of the nonsense written above, I write volume = GetVolumeOfPyramid(base, height) then suddenly everything becomes a lot clearer, and it's perfectly okay to have magic numbers inside the function (return base * height / 3) because it's obvious that they're just part of the formula.

    The key here is of course to have short and simple functions. This doesn't work for functions with 10 arguments and 30 lines of calculations. Use function composition or constants in that case.

  • Domain/business rules

    This one is always the gray area because it depends on what exactly the value is. Most of the time, it's these particular magic numbers that are candidates for turning into constants, because that makes the program easier to understand without complicating the program logic. Consider the test if Age < 19 vs. if Age < LegalDrinkingAge; you probably can figure out what's going on without the constant, but it's easier with the descriptive title.

    These may also become candidates for function abstraction, for example function isLegalDrinkingAge(age) { return age >= 19 }. The only thing is that often your business logic is a lot more convoluted than that, and it might not make sense to start writing out dozens of functions with 20-30 parameters each. If there isn't a clear abstraction based on objects and/or functions then resorting to constants is OK.

    The caveat is, if you're working for the tax department, it becomes really, really burdensome and honestly pointless to write AttachForm(FORM_CODE_FOR_SINGLE_TAXPAYER_FILING_JOINTLY_FOR_DEPRECIATION_ON_ARMPIT_HAIR). You're not going to do that, you're going to AttachForm("B-46") because every single developer who ever has worked or ever will work there is going to know that "B-46" is the form code for a single taxpayer filing blah blah blah - the form codes are part of the domain itself, they never change, so they're not really magic numbers.

    So you have to use constants sparingly in business logic; basically you have to understand whether or not that "magic number" is actually a magic number or if it's a well-known aspect of the domain. If it's domain, then you don't soft-code it unless there's a really good chance it will change.

  • Error codes and status flags

    These are never okay to hard-code, as any poor bastard who has ever been hit with the Previous action failed due to error code 46 can tell you. If your language supports it, you should be using an enumeration type. Otherwise, you'll usually have an entire file/module full of constants specifying the valid values for a particular error type.

    Don't ever let me see return 42 in an error handler, capiche? No excuses.

I probably left out several scenarios but I think that covers most of them.

So, yeah, it's sometimes acceptable practice to hard code stuff. Just don't be lazy about it; it should be a conscious decision rather than plain old sloppy code.

share|improve this answer

There are various reasons for assigning an identifier to a number.

If the number might change, it should have an identifier. It's much easier to find NUMBER_OF_PLANETS than to search for every instance of 9 and consider whether it should be changed to 8. (Note that user-visible strings might have to change if the software ever has to be used in a different language, and that's a hard thing to predict in advance.)

If the number is hard to type in any way. For constants like pi, it's better to give one maximum-precision definition than to retype it in several places, possibly inaccurately.

If the number occurs in different places. You shouldn't have to look at two uses of 45 in adjoining functions and wonder if they mean the same thing.

If the meaning isn't instantly recognizable. It's safe to assume that everybody knows what 3.14159265... is. It isn't safe to assume that everybody will recognize the gravitational constant, or even pi/2. ("Everybody" here does depend on the nature of the software. Systems programmers can be expected to know the octal representation of Unix permission bits or the like. In naval/marine architecture software, checking the Froude number of a proposed hull and speed to see if it's 1.1 or greater might be perfectly self-explanatory to anybody who should be working on it.)

If the context isn't recognizable. Everybody knows there are 60 minutes in an hour, but multiplying or dividing by 60 may be unclear if there's no immediate indications that the quantity is a time value or a rate value.

This gives us criteria for hard-coding literals. They should be immutable, not hard to type, occurring in one place or context only, and with recognizable meaning. There's no point in defining 0 as ARRAY_BEGINNING, for example, or 1 as ARRAY_INCREMENT.

share|improve this answer

Is it ever a good idea to hardcode values into our applications?

I hardcode values only if the values are specified in the Specification (on a final release of the specification), e.g. The HTTP OK response will always be 200 (unless it changes in the RFC), so, you will see (in some of my codes) constants like:

public static final int HTTP_OK = 200;

Otherwise, I store constants in the properties file.

The reason why I specified specifications, is that changing constants in specifications requires change management, in which, the stakeholders will review the change and approve/disapprove. It never happens overnight and takes months/years for an approval. Don't forget that many developers uses specifications (e.g. HTTP) so changing it means breaking millions of systems.

share|improve this answer
  • if the value can change, and indeed might change, then soft-code it whenever possible as long as the effort involved does not exceed the expected return
  • some values cannot be soft-coded; follow Jonathan's guidelines in those (rare) cases
share|improve this answer

It depends what you consider hardcoding. If you try to avoid any and all hardcoded things, you end up in softcoding territory, and make a system that only the creator can manage (and that's the ultimate hardcode)

Plenty of things are hardcoded in any reasonable framework and they work. i.e. there's no technical reason why I shouldn't be able to change the entry point of a C# application (static void Main), but hardcoding that does not create any problems for any user (except the occasional SO question)

The rule of thumb I use is that anything that can and will change, without affecting the state of the whole system, should be confugurable.

So, IMHO, it's silly not to hardcode things that are never changing (pi, gravitational constant, a constant in a mathematical formula - think volume of a sphere).

Also it's silly not to hardcode things or processes that will have an impact on your system that will require programming in any instance, i.e. it's wastefull to allow the user to add dynamic fields to a form, if any added field would require the maintenance developer to go in and write some script that will make that thing to work. Also it's stupid (and I've seen it a few times in enterprise environments) to create some configuration tool, so nothing is hardcoded, yet, only the developers in the IT department can use it, and it's only slighty easier to use it than to do it in Visual Studio.

So, bottom line, whether a thing should be hardcoded is a function of two variables:

  • will the value change
  • how will a change in the value affect the system
share|improve this answer

I recently coded a MySQL function to properly calculate the distance between two lat/long pairs. You can't just do pythagorus; longitude lines get closer together as latitude increases toward the poles, so there's some kinda hairy trig involved. Point is, I was pretty torn about whether to hard-code the value representing the earth's radius in miles.

I ended up doing it, even though the fact is, lat/lng lines are much closer together on, say, the moon. And my function would drastically underreport distances between points on Jupiter. I figured the odds of the website I'm building having an extraterrestrial location get entered is pretty slim.

share|improve this answer

I've noticed that any time you can extract data from your code, it improves what's left. You start noticing new refactorings and improving whole sections of your code.

It's just a good idea to work towards extracting constants, don't consider it some stupid rule, think about it as an opportunity to code better.

The biggest advantage would be the way you might find similar constants being the only difference in groups of code--abstracting them into arrays has helped me reduce some files by 90% of their size and fix quite a few copy & paste bugs in the meantime.

I've yet to see a single advantage to not extracting data.

share|improve this answer

Well it depends if your language is compiled. If it's not compiled, it's not a big deal, you just edit the source code, even if it will be slightly delicate for a non programmer.

If you are programming with a compiled language, this is clearly not a good idea, because if the variables change, you have to recompile, which is a big waste of time if you want to adjust this variable.

You don't need to make some slider or interface to dynamically change his variable, but the least you could do is a text file.

For example with my ogre project, I'm always using the ConfigFile class to load a variable I have written to a config file.

share|improve this answer

Two occasions where constants are (in my opinion at least) OK:

  1. Constants that relate to nothing else; you can change those constants whenever you like without having to change anything else. Example: The default width of a grid column.

  2. Absolutely immutable, precise, obvious constants, like "number of days per week". days = weeks * 7 Replacing 7 with a constant DAYS_PER_WEEK hardly provides any value.

share|improve this answer

I do agree completely with Jonathan but as all rules there are exceptions...

"Magic number in the spec: Magic number in the code"

Basically states that any magic numbers that remains in the spec after reasonable attempts to get descriptive context for them should be reflected as such in the code. If magic numbers remain in the code every efforts should be made to isolate them and make them clearly linked to their point of origin.

I have performed a few interfacing contracts where it is necessary to populate messages with values mapped from the database. In most cases the mapping is fairly straight forward and would fit in Jonathan's general guide lines but I have encountered cases where the target message structure was just plain awful. More than 80% of the values that had to be passed down in the structure were constants enforced by the specification of the distant system. this coupled with the fact that the message structure was gargantuan made that a LOT of such constants had to be populated. In most cases they did not provide a meaning or reason, just said "put M here" or "put 4.10.53.10100.889450.4452 here". I did not attempt either to put a comment next to all of them it would have rendered the resulting code unreadable. I did however make sure the code sections where these magic values appear are properly isolated and that their containers (classes, packages) named appropriately to point directly to the specification enforcing them.

That said, when you think about it... it's pretty much all about making it obvious...

share|improve this answer

If you're hardcoding the value of the earth's gravitational constant, noone's going to care. If you hardcode the IP address of your proxy server, you're in for trouble.

share|improve this answer
1  
You might need more precision for earth's gravitational constant, so hardcoding it several times might lead to problems. –  user281377 Apr 14 '11 at 12:24
1  
Peter Noone? From Herman's Hermits? –  David Conrad Apr 14 '11 at 12:48
    
The gravitational acceleration on the Earth is pretty much 9.81 m/s^2 for most latitudes and altitudes (of course, if you're searching for oil underground, or shooting ICBMs over the North Pole, knowing the variation in gravity is very important to a lot more decimal places), with the gravitational acceleration on other planets being a different number, but as far as I know, the gravitational constant is constant around the universe. There is a lot of physics that would have to change if g were variable. –  Tangurena Apr 14 '11 at 18:31

Mostly no, but I think that is worth noting that you will have the most problems when you start duplicating the hard-coded value. If you don't duplicate it (ex. use it just once in the implementation of a class) then not using a constant might be alright.

share|improve this answer

Is it ever a good idea to hardcode values into our applications? Or is it always the right thing to call these types of values dynamically in case they need to change?

Alice: Oh, no, no. I was just wondering if you could help me find my way.
Cheshire Cat: Well that depends on where you want to get to.
Alice: Oh, it really doesn't matter, as long as...
Cheshire Cat: Then it really doesn't matter which way you go.

Say, just what kind of applications are you writing anyway?

share|improve this answer
    
Why the downvote? More importantly, why an uninformative downvote without even the courtesy of leaving a comment? I would make the claim my answer is on point, and valid, a the proper answer to the original question is "mu". en.wikipedia.org/wiki/Mu_(negative). The questioners question cannot be properly answered without more context. Perhaps the question should be tossed away as vague. –  Jerry Apr 14 '11 at 4:19
2  
I disagree, it does not matter what the context is the question is about the practice of using hard coded values. This applies to almost any context. The fact however that the correct answer to this may depend on the context does, in my opinion, reveal much about the dogma of never using hard coded values. PS I was not the down vote though, just responding to your comment. This said I would venture in saying the mysterious down voter might have found your answer should have been better served as a comment to the question. –  Newtopian Apr 14 '11 at 5:16
1  
Thank you Newtopian for the comment. If I was writing an application with an expected international (many languages), commercial, market for say, Windows 7, can you provide me with the answer of when it is a good idea to hardcode constants into the code? I can't think of any, which may reflect my poor imagination and knowledge. And yet, in a comment to the highest rated answer in this thread says that yes, in the context of an embedded system it is a good idea. It seems to me, that context is everything for this question, and asking questioner what apps he is writing is key. –  Jerry Apr 14 '11 at 6:04
    
I admit that for UI related fields this would never be a good idea, but there are plenty of examples of software that never reach an end-user. Application dealings with transactional events following a specific protocol comes to mind (see my own answer for such example). That said, I do not think it is a good idea ever to hard code values, just that sometimes hard coding may be the lesser of two evils. unrelated note... One thing I enjoy most of this site is that we can have good technical discussion with very little displeasure of trolls and other pyromaniacs ! cheers :-) –  Newtopian Apr 14 '11 at 6:48
2  
you missed my point, both of them ! The question is valid regardless of the type of application because all programming tasks will eventually have to use a constant or a variable at one point or another. The OP as asking if it is a good idea to always make them variables or if it's ok sometimes to have constants or even directly hard code the value directly. If your answer depends on the type of application then state so in the answer, but if the answer is asking more details then it is not an answer at all and should have been a comment, hence the down votes. –  Newtopian Apr 14 '11 at 11:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.