[kforge-dev] named constants, magic values

Mon Dec 11 14:43:32 UTC 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 
> DB_TYPE.

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

Yes, but...

> 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 
technical aspects.

>
> 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!

Bye bye,

John.