Your question has multiple aspects.
(BTW: I'm assuming your code to be Java, so my answer covers some technical aspects specific to that language)
Who needs these values?
You need them inside the
setVolume() method. But you'd better communicate the limits of
val to a potential user, so he isn't surprised that
setVolume(100) has the same effect as
setVolume(10). You should do that in a Javadoc comment, and maybe by making the limit values accessible. So it might make sense to make them
public static final fields of your class.
Where can you declare them to really become constants?
In Java, declaring a variable
final just means that, after initialization, you promise not to change its value later. It still is a variable to be allocated on the stack, visible in the debugger and so on (of course, compilers and the HotSpot engine are quite clever, so maybe they'll be able to detect that
VOL_MIN is just meant to be another name for a literal
Without relying on compiler optimizations, placing such a "constant" (a
final variable) into a method means that every time you enter the method, a word on the stack is allocated, the initial value is computed (not in your case, as it's a literal integer) and copied into the stack word. So, using such a "constant" comes with a (tiny, depending on the level of optimization) performance penalty.
In contrast, a static final field (declared outside any method) is initialized only once when loading your class, and the language specification allows the compiler to replace usages of the field with just the literal value. And from personal experience I know that that happens. So
static final fields don't have a performance penalty over plain literals.
So, where's the place to declare your constants?
- Inside the method where they're used, they don't really become constants, but you probably won't notice the difference. Use that if you're concerned about tightest scope possible. But please make sure that they're really not useful for the outside world.
private static final fields of your class, they're visible to all methods inside your class, so the scope is slightly larger. And they become real constants without a performance penalty over using the values as literals.
public static final fields of your class, they become visible to all users of your class, so the scope is quite open. They become real constants without a performance penalty over using the values as literals. Being part of your class shows that these constants are related to properties of your class.
public static final fields of a "constants" class, they're visible to all users, so the scope is quite open. They become real constants without a performance penalty over using the values as literals. Being in a class unrelated to your
setVolume() method makes it hard to see the relationship with this method.
If you decide that the values aren't needed outside the
setVolume() method, I'd go for
private static final fields or (personal opinion) just use the plain literal values (in such a short, simple method, I don't see a readability advantage in introducing the names).
If you decide that the values are useful also for users of the
setVolume() method, I'd use
public static final fields in the same class.
If the values affect multiple methods in multiple classes, place them in a "constants" class.
Whatever you do, introducing a name for a literal value shouldn't take away information, so check the various possibilities with your favorite IDE to see if it shows the value when hovering over references of the constant.