Suppose you wanted to define a constant whose value was Zeta[3], and call it AperysConstant. If you want to make AperysConstant behave like E, Pi, etc., you would do:

SetAttributes[AperysConstant, Constant];
NumericQ[AperysConstant] = True;
N[AperysConstant, _] = Zeta[3];

Then, AperysConstant behaves like Pi. Below I give some examples:

N

N[AperysConstant]
N[Pi]

N[AperysConstant, 20]
N[Pi, 20]

(* 1.20206 *)
(* 3.14159 *)

(* 1.2020569031595942854 *)
(* 3.1415926535897932385 *)

Dt

Dt[x^AperysConstant,x]
Dt[x^Pi, x]
Dt[x^y, x]

(* AperysConstant x^(-1+AperysConstant) *)
(* \[Pi] x^(-1+\[Pi]) *)
(* x^y (y/x+Dt[y,x] Log[x]) *)

Note the difference between AperysConstant and y above.

Less

 1 < AperysConstant < 2
 3 < Pi < 4

(* True *)
(* True *)

Sign

 Sign[AperysConstant-2]
 Sign[Pi-4]

(* -1 *)
(* -1 *)

Inexact arithmetic

 AperysConstant + 1.1`20
 Pi + 1.1`20

(* 2.3020569031595942854 *)
(* 4.2415926535897932385 *)

Variables

Variables[1 + Pi x + x^2]
Variables[1 + AperysConstant x + x^2]

(* {x} *)
(* {x} *)

seems to me it's a lot easier to define your constant as a variable and then write your code so it doesn't get changed.

I work on a substantially larger program. I've written that many lines, with a few to spare. As regards defining constants in WL, setting the Protected and perhapsLocked attribute(s) is a good idea. Use of a "function", as in @SanderHuisman's approach, is fine for some purposes, perhaps overkill for others.

Short of With[{...}...] style macroization of values, there is no support for creating absolutely immutable "constants". What we most often do involves locking symbols, sometimes exported from specialized contexts. Works well. Not worth trying to make something so simple absolutely foolproof; if your project team is going to mess it up, your problem is with the team.

As for localizing variables vs. maintaining globals, this is largely a separate issue, and there is no doubt that having globals in use can cause trouble. Best I think is to use lists or Association or other structures that encapsulate variable lists. I agree that having "globals" that are constants is acceptable.

Thanks to everybody.

@Frank: This is not a constant, just a normal variable, which can by changed by anything throughout the program. That is of course what I am doing at the moment, but makes me unhappy.

n = 2;

@Sander: Sounds reasonable, but somewhat strange. Is there really nothing like a constant datatype within WL? Hence define a normal global symbol and then protect it? But ok, why not?

n=2;SetAttributes[n,{Constant,Protected}]

@David: Explicitly replace constants through coding wherever they appear? That's a joke. It would make the coding unreadable.

mm 3 + bb /. constants

@Sam: Read the docs, I know. I did that. Maybe with your explicit links I can get nearer to that trivial feature of defining a constant.

For the moment I think, Sanders method is the best.

Alternatively, it can be done by defining a function with 0 arity (nullary):

Unprotect[MyConstant]
ClearAll[MyConstant]
N[MyConstant[],p_:{MachinePrecision, MachinePrecision}] := N[Log[2],p]
SetAttributes[MyConstant,{NumericFunction,Constant,Protected}]

MyConstant[]  (* remains unevaluated *)
Positive[MyConstant[]]  (* positive will trigger an N and then return True *)
NumericQ[MyConstant[]] (* NumericQ 'reads' the NumericFunction attribute *)

MyConstant[]+1.0    (* constant + machine precision number will trigger numeric evaluation of the constant *)
MyConstant[]+1.0`100 (* will trigger appropriate numerical evaluation *)

Because of the symbolic nature and dynamic typing of WL it is not that easy. Something can be 'constant', but non-numeric (think e.g. a string, a formula, a symbol, or ...). So functions like derivative and Positive, NumericQ have to 'act' differently depending on the type. Note that Attributes plays a vital role in the WL and also note that the first two of my lines are strictly not needed.

What do you want to do with it? if you just want to have a 'variable' which can not be changed, you could simply use Protect[...] (equivalent to SetAttributes[...,Protected]). If you want it to correctly interact with Dt and so on, you have to specify more 'stuff'. To sum up:

With great symbolic computation comes great carefulness

Hello Sander,

why do you write

N[MyConstant[],p_:{MachinePrecision, MachinePrecision}] := N[Log[2],p]

the MachinePrecison twice?

You should take a look at Contexts and generally some quite educational set of tutorials Modularity and the Naming of Things.

n = 2;