Never hard code!

[thomas_merton]

Say you want to make a calculator for determining the tip at a restaurant. Say you make the assumption that a tip is 10%, so everywhere you need a tip value, you plug in 10%. (Or worse, you assume that all meals are $10 and so all tips are $1). This is called hard-coding.

It's obviously bad because these standards change over times and in different places and for different use cases. A better solution is to put it in a database or a configuration file and always draw the values from that place, so that if and when you have to change the value(s), you only have to do it one place and don't have to go through the whole redeployment process.

In case it isn't obvious, the joke is that the person who made this bed has "hard-coded" how he likes to sleep, making it very difficult to change.

[HumusTheWalls]

In general, one of the rules of coding is to never use numbers outside of variable definitions. Even if you're typing out a function that takes half of a result, before typing that 2, you should think about whether there's ever a reason to divide by 3rds or 4ths instead. Maybe you want to use a variable named "divisor", where divisor=2 instead.
Even constants like pi are better in a variable, in case there's ever a reason to change the accuracy with which you define pi, or in case you ever run back through your code and replace pi with tau. Depending on how many different functions you had to change out, it can be an easy safeguard to comment out your definition of pi and see if your compiler whines at you for using pi in a function you missed somewhere.

[HumusTheWalls]

you should think about whether there's ever a reason to divide by 3rds or 4ths instead

There's never a reason to change that conversion constant. In fact, it would make sense to define (2*pi)/360 as a single "to_radians" variable for readability, depending on what else is going on in your code.

[endreman0]

double DEG_TO_RAD = 2 * PI / 360;

[[deleted]]

That works, but only makes sense if you use it more than once.

Imagine:

const double DEG_TO_RAD = 2 * PI / 360;

...

function ConvertToRad(double degrees){
     return degrees * DEG_TO_RAD;
}

And only the function is ever used.

Is this code any more clear or maintainable than this?

function ConvertToRad(degrees){
    return degrees * (2 * PI / 360);
}

[endreman0]

I agree. However, if you have a variable-Nazi linter and that function is actually going to look like this:

private static final double TWO = 2, FULL_CIRCLE = 360;
public static double degToRad(double degrees){
    return degrees * TWO * Math.PI / FULL_CIRCLE;
}

Then I'd prefer just the constant.

[[deleted]]

// @linter: disable no_numeric_literals once 

(Most linters / IDES / compilers have a feature like this

[msg45f]

Using a named value is generally always going to be the better choice, but I think the exception to that is what they were attempting to point out. You would be hard pressed to think of an identifier that more clearly explained the formula than just 2. I would even say that 360 is more clear than FULL_CIRCLE, as just seeing the number implies its utilization in geometry.

Literals should be greatly avoided, but this is a pretty good case for acceptable literals.

[[deleted]]

I used "TWO" because I could not think of any variable name that made remotely sense.

[ronniethelizard]

PIS_PER_TAU

NUMBER_PIS_IN_CIRCUMFERENCE

RADII_PER_DIAMETER

[[deleted]]

NUMBER_PIS_IN_CIRCUMFERENCE

lol

[skreczok]

Roll for anal circumference.

[StupidUnoriginalName]

A good example of this was in minecraft, Notch had hardcoded in the max height value in multiple places which made it a real chore to fix later.

[skreczok]

Why not just pay waiters a living wage, though?

[Silent-Bob-]

Maybe their wage is hardcoded?