[kforge-dev] named constants, magic values
john.bywater at appropriatesoftwarefoundation.org
Mon Dec 11 14:43:32 GMT 2006
Rufus Pollock wrote:
> 1. There is no gain in readability since the dictionary values are
> usually named as descriptively (if not more descriptively) than the
> 'constants' e.g. db.type versus DB_TYPE.
I can see no gain, and no loss of readability. I can't see why one is
more or less descriptive than the other.
But readability isn't the main concern here....
> 2. In a compiled language such as C or java using named constants is a
> way to avoid errors. However in python the only way to catch an error
> is for that code to be run (in particular exercised by a unit test).
> In such a case the error will be caught whether we use 'db.type' or
Without named constants, in Python it is caught by a dictionary
KeyError, rather than a NameError before the dictionary call is made. I
think it is preferable to catch this error with a NameError, because it
is much simpler: you know the name is the problem. You don't need to
decide whether it is the dictionary key that is wrong, or whether it is
the dictionary that has been constructed inadequately. [Maintainer
seconds start to tick away....]
OTOH with named constants, if the dictionary has been badly constructed,
there will be a KeyError and not a NameError. Such immediate
disambiguation adds to maintainer efficiency, and helps the project to
stay away from the software crisis.
Importantly, the definitions of the named constants provide clear
normativity, which is lost within a distribution of magic values.
> 3. Indirection: what I meant by this was that if I see
> self.dictionary['db.type'] and want to know where it is defined or
> what its value is i know to look in the system dictionary (or
> configuration file) for db.type while
> with DB_TYPE I first need to go to dm.dictionarywords or
> kforge.dictionarywords and discover that DB_TYPE = 'db.type' and then
> go off and look in the system dictionary.
No because you would just look for DB_TYPE in the system dictionary, not
its string value.
> To my mind this seems to have clearly added 'another layer'.
It adds one layer, not 'another' layer. And an important one. If you
don't understand these subtleties, and want to oppose forcefully rather
than perhaps being humble and inquiring, I am bound to suggest that you
consider sticking to the product owner role, and don't speak about
> Thus, given that (a) we are using named constants for already
> well-named configuration/system dictionary lookups
The discussion is about the use of named constants instead of magic
values, not whether those magic vaues are good values.
> (b) using python
Which matters not. There is a recipe in the Python Cookbook for named
constants. Recipe 5.15, p193.
> I am not convinced that in this case the benefit/cost ratio is
> positive, and that therefore their introduction is 'progressing' the code.
Sure. That's why I have asked you to focus on the product owner role and
your business decisions, and to leave technical decisions to an
experienced engineer such as myself.
I'm not convinced that you have enough experience maintaining code to
know what is progressive and what is regressive, particularly in respect
of maintainer efficiency.
Certainly, having to defend the merits of named constants against
forceful opposition makes me feel that this isn't an efficient place to
spend my time.
> Nevertheless, I entirely understand your motivation for doing this
I'm not really convinced you do.
> and given that the impact either way is fairly small I am ok with
> things being left as they are.
Well thank goodness for that!
More information about the kforge-dev