[kforge-dev] named constants, magic values

Mon Dec 11 11:43:25 UTC 2006

John Bywater wrote:
>  From a recent commit message:
> 
> <quote>I am not entirely clear what the benefit of these type of changes 
> are -- i.e. using DB_TYPE instead of 'db.type'? What does this extra 
> layer of indirection provide to compensate for the extra 
> indirection?</quote>
> 
> If the question is, what do named constants provide? the answer is that 
> named constants provide maintainability due to compile time checking.
> 
> The 'types of changes' that change magic values into named constants 
> provide the benefit of having more named constants, therefore more 
> maintainable code, and therefore progress the code. (OTOH to revert such 
> changes would be to regress the code.)
> 
> As there isn't any indirection involved in magic values before named 
> constants are introduced, there isn't any extra indirection to be 
> compensated for.

[snip]

I would entirely agree that named constants are valuable in the case of 
'magic values'. However I am not so convinced of their value for looking 
up attributes in the system dictionary in an interpreted language such 
as python. Specifically:

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. Furthermore in this case

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.

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. To my mind 
this seems to have clearly added 'another layer'.

Thus, given that (a) we are using named constants for already well-named 
configuration/system dictionary lookups (b) using python I am not 
convinced that in this case the benefit/cost ratio is positive, and that 
therefore their introduction is 'progressing' the code. Nevertheless, I 
entirely understand your motivation for doing this and given that the 
impact either way is fairly small I am ok with things being left as they 
are.

Regards,

Rufus