It is very clear if you read the very first sentence of the question
that this question is not about appropriate uses like
eliminating magic numbers, it is about terrible mindless foolish
consistency at best. Which is what this answer addresses
Common sense tells you that const char UPPER_CASE_A = 'A';
or const char A = 'A'
does not add anything but maintenance and complexity to your system. const char STATUS_CODE.ARRIVED = 'A'
is a different case.
Constants are supposed to represent things that are immutable at runtime, but may need to be modified in the future at compile time. When would const char A =
correctly equal anything other than A
?
If you see public static final char COLON = ':'
in Java code, find whomever wrote that and break their keyboards. If the representation for COLON
ever changes from :
you will have a maintenance nightmare.
Obfuscation:
What happens when someone changes it to COLON = '-'
because where they are using it needs a -
instead everywhere? Are you going to write unit tests that basically say assertThat(':' == COLON)
for every single const
reference to make sure they do not get changed? Only to have someone fix the test when they change them?
If someone actually argues that public static final String EMPTY_STRING = "";
is useful and beneficial, you just qualified their knowledge and safely ignore them on everything else.
Having every printable character available with a named version just demonstrates that whomever did it, is not qualified to be writing code unsupervised.
Cohesion:
It also artificially lowers cohesion, because it moves things away from the things that use them and are related to them.
In computer programming, cohesion refers to the degree to which the
elements of a module belong together. Thus, cohesion measures the
strength of relationship between pieces of functionality within a
given module. For example, in highly cohesive systems functionality is
strongly related.
Coupling:
It also couples lots of unrelated classes together because they all end up referencing files that are not really related to what they do.
Tight coupling is when a group of classes are highly dependent on one
another. This scenario arises when a class assumes too many
responsibilities, or when one concern is spread over many classes
rather than having its own class.
If you used a better name like DELIMITER = ','
you would still have the same problem, because the name is generic and carries no semantic. Reassigning the value does no more to help do an impact analysis than searching and replacing for the literal ','
. Because what is some code uses it and needs the ,
and some other code uses but needs ;
now? Still have to look at every use manually and change them.
In the Wild:
I recently refactored a 1,000,000+ LOC
application that was 18 years old. It had things like public static final COMMA = SPACE + "," + SPACE;
. That is in no way better than just inlining " , "
where it is needed.
If you want to argue readability you need to learn you to configure your IDE to display whitespace
characters where you can see them or whatever, that is just an extremely lazy reason to introduce entropy into a system.
It also had ,
defined multiple times with multiple misspellings of the word COMMA
in multiple packages and classes. With references to all the variations intermixed together in code. It was nothing short of a nightmare to try and fix something without breaking something completely unrelated.
Same with the alphabet, there were multiple UPPER_CASE_A
, A
, UPPER_A
, A_UPPER
that most of the time were equal to A
but in some cases were not. For almost every character, but not all characters.
And from the edit histories it did not appear that a single one of these was ever edited or changed over the 18 years, because of what should now be obvious reason is it would break way too many things that were untraceable, thus you have new variable names pointing to the same thing that can never be changed for the same reason.
In no sane reality can you argue that this practice is not doing anything but starting out at maximum entropy.
I refactored all this mess out and inlined all the tautologies and the new college hires were much more productive because they did not have to hunt down through multiple levels of indirection what these const
references actually pointed to, because they were not reliable in what they were named vs what they contained.
«
and»
) as quotation marks instead of English's standard"
(or nicer-looking“
and”
). Apart from that, it just sounds like a set of magic characters. Assuming two instances ofCharacterClass
calledenglishChars
andfrenchChars
, it's possible thatenglishChars.LEFT_QUOTE
might be“
, whilefrenchChars.LEFT_QUOTE
might be«
.File.separator
. The class tells you the type of separator. Having a class namedConsts
orConstants
provides no context and makes constants harder to use correctly.