Constant conformity

I understand, as a participant in the Cattle Drive, that it is my job to be flexible and conform to the style guide.

But I don't understand the following reasoning about Constants, and would prefer to understand it rather than simply abide by it.

All other identifiers, including (but not limited to) fields, local variables, methods and parameters, will use the following naming convention. This includes identifiers for constants.

Reasoning: Using all upper case, as traditionally done in C, is a violation of OO abstraction. For example, a variable which starts out as a constant may be refactored later to not be a constant.

Why is using upper case relevant to whether something has OO abstraction or not?

The example makes no sense to me. If I refactor a constant to a variable, I change the case. Case changes are easy. And the upper case adds clarity for a future programmer--they will be less likely to mistakenly try to use the variable as something mutable if it is visually distinct.

Is making something "final" a violation of OO abstraction? There are many, many situations where one imposes finality to prevent further modifications down the road.

Thanks for any insights offered.

It's arbitrary -- it's in the Javaranch style guide, so when programming for the Javaranch, we follow it.

I believe that the reason behind it is that when reading the code you shouldn't have to know whether it is a variable or a constant, just what it means. I could be wrong.

I work with other teams where the style guide is different, and the main thing is to be able to flexibly follow the style guide of the place you are working at.

My $0.02