public static final Naming Conventions

[Stevens Miller]

Winston Gutkowski wrote:...you should be concerning yourself with the semantics of that problem, and not bits and bytes - in my (I'm sure by now, nauseating) terminology: the "what", not the "how".

I'm increasingly of the mind that this distinction is not as black-and-white as some think it is. While there is a lot of enthusiasm for "declarative programming," much of it seems to come from people who find algorithms confusing. No matter how much we would like to say that we are interested more in the "what" than in the "how," someone, somewhere, must provide the "how." My personal view is that managers seem to think "what" is very important, mostly because they don't know "how," while programmers who work for them are the ones who know "how" to do the "what." "How" is what I'm doing here. (Actually, the precise difference may very well be black-and-white, but not in what I find to be a useful way: I've read that the only definitive difference between declarative programming and imperative programming is that the former requires immutability. There are some magnificently abstruse papers on this, most of which I don't understand, that all seem, in the end, to ignore the fact that "what" I want to do is a goal, and "how" I do it is the means to reach that goal. You can have all the "what" you want, but you get nowhere without the "how.") [Disclaimer: I have high regard for Winston Gutkowski's programming skill, and am sure he can deliver as much "how" as anyone else.]

To my mind a constant is something that is set at creation time and cannot be changed - ie, it either doesn't exist, or it has a fixed value - which further suggests to me that, whatever it is, it's immutable.

Sure. That's what "final" means, right?

It does, however, have scope. A static final field in a class, or an Enum instance, is likely to "live" for as long as the JVM that loads it exists; but a final field in a class will live for as long as its associated object does. I'd categorise both as constants; just at different levels

Quite. I think you've identified an important scope here: the duration of a loaded JVM. That's pretty close to what I think we mean by "run time," though "run time" is really a moment, while the life-time of a loaded JVM is a span. My "constants" both endure for the life-time of a loaded JVM (let's call that "JVM time"). One happens to have been set at compile time, the other is subject to change after compile time but is fixed for a given JVM time. Thus, both are static final and both are fixed for a given JVM time.

- and of course, with different naming conventions.

A static final and an instance final have different naming conventions. That's canon, and I have no quibble with it. I am asking about two constants that are both static final, both of which are immutable for a given JVM time, but only one of which was set at compile time. For the constant set at compile time, I am satisfied that ALL_CAPS is the convention to use. For the static final that was not set at compile time, but is set for a given JVM time, what convention do you propose?

[Junilu Lacar]

Stevens Miller wrote:My personal view is that managers seem to think "what" is very important, mostly because they don't know "how," while programmers who work for them are the ones who know "how" to do the "what." "How" is what I'm doing here.

My experience is that managers think that "when" is more important, they don't care about the who, what, where, why, but just "how soon?", "how much?", and "how well?" in that order.

It's the other developers who care or should care more about what and why over how. How is definitely a concern that shouldn't be taken lightly but effort must be made to keep it from consuming and overwhelming the attention of the reader and the code, hence the principle of separation of concerns and maintaining single levels of abstraction.

A static final and an instance final have different naming conventions. That's canon, and I have no quibble with it. I am asking about two constants that are both static final, both of which are immutable for a given JVM time, but only one of which was set at compile time. For the constant set at compile time, I am satisfied that ALL_CAPS is the convention to use. For the static final that was not set at compile time, but is set for a given JVM time, what convention do you propose?

Honestly, I think you're overthinking this. I think that as far as semantics goes, the reader shouldn't really have to care whether the "constant" value was set at compile time or not. That's an implementation detail that shouldn't make a difference at a high level of abstraction. As I alluded to before, if you get stuck in a gray area, perhaps the best way out of it is to redraw the lines and refactor with a different perspective in mind, one that results in making the gray area issue moot and therefore your way forward decidedly either black or white.

[Stephan van Hulst]

Stevens Miller wrote:There are some magnificently abstruse papers on this, most of which I don't understand, that all seem, in the end, to ignore the fact that "what" I want to do is a goal, and "how" I do it is the means to reach that goal. You can have all the "what" you want, but you get nowhere without the "how."

The point of declarative programming is to drive the 'how' out of the hands of the programmer, and into the tendrils of the platform or machine. You solve problems by describing them to the machine, and the machine then knows how to solve the problem.

To my mind a constant is something that is set at creation time and cannot be changed - ie, it either doesn't exist, or it has a fixed value - which further suggests to me that, whatever it is, it's immutable.

Sure. That's what "final" means, right?

Not to me, and I imagine not to Winston either. The final keyword can be used to make a variable's value constant. For a reference type, that means you can not make the variable point to a different object, but it doesn't mean that you can't change the object itself, something we're usually much more interested in. To me a constant is a variable that holds a final reference to an immutable type whose value can be computed at compile time.

My "constants" both endure for the life-time of a loaded JVM (let's call that "JVM time"). One happens to have been set at compile time, the other is subject to change after compile time but is fixed for a given JVM time. Thus, both are static final and both are fixed for a given JVM time.

This is where I disagree with Bear and Campbell. My reason for this is unit-testing. A unit test needs to operate in a deterministic way, isolated from all outside influence. As long as you don't change a unit test, and you don't change the code you let it test, it should always return the same output. You can't do that if the code you test uses global state that may appear different between runs. In that case, during one run a unit-test could succeed, and during another run the same unit-test could fail, without you changing the code under test. This is BAD. You may argue that the 'constant' is part of the code under test, but it flies in the face of what we consider units.

A static final and an instance final have different naming conventions. That's canon, and I have no quibble with it. I am asking about two constants that are both static final, both of which are immutable for a given JVM time, but only one of which was set at compile time. For the constant set at compile time, I am satisfied that ALL_CAPS is the convention to use. For the static final that was not set at compile time, but is set for a given JVM time, what convention do you propose?

The convention doesn't make a distinction, so you would use ALL_CAPS for both cases. My point is that how you name the 'JVM-time constant' is irrelevant, because you shouldn't use such 'constants' in the first place. If I made a new language with new naming conventions, I'd only allow the declaration of global data if their value can completely be determined at compile time, and if their value doesn't change afterwards. This would include setting their value from resource files, which need to be present at compile time. Even then, what makes them so important that we need to capitalize their identifiers? I think a much more important distinction to make is between fields and local variables. I probably wouldn't use all caps for either of them though, because that would get tiring very quickly. If we can cope without a visual distinction between fields and and local variables, then why do we need a distinction between constants and variables?

[Stephan van Hulst]

For Java, a convention that makes a lot more sense to me is to write all static variables in all caps. I think that would clearly convey "here be dragons".

[Junilu Lacar]

Stephan van Hulst wrote:For Java, a convention that makes a lot more sense to me is to write all static variables in all caps. I think that would clearly convey "here be dragons".

And those who use them must assume the risk of getting burned.  

[Stevens Miller]

Good points, Junilu and Stephan. Most helpful.

My wife came up with an option I rather like: For the JVM time constants, don't grant direct access; provide a getter instead, but no setter. This finesses the question of what convention to use for the variable, since it is not available to client code by name, while making its value available via a read-only mechanism. This also allows for the possibility that what is a JVM time constant today may become a JVM time variable tomorrow. In some games, players can come and go, literally by connecting and disconnecting their controllers. While it's a level of complication I'd prefer to deal with later, it would be nice to allow for that possibility. A getter allows for access to a value that is final now, but may not always be.

[Stevens Miller]

Stephan van Hulst wrote:

Stevens Miller wrote:

Winston wrote:To my mind a constant is something that is set at creation time and cannot be changed - ie, it either doesn't exist, or it has a fixed value - which further suggests to me that, whatever it is, it's immutable.

Sure. That's what "final" means, right?

Not to me, and I imagine not to Winston either. The final keyword can be used to make a variable's value constant. For a reference type, that means you can not make the variable point to a different object, but it doesn't mean that you can't change the object itself, something we're usually much more interested in.

Doh! I got so concerned with integer constants that I forgot all about this. Thanks.