Managing constants in application

Question

Our application is having 2 parts a web app running ROR and a web service running Sinatra. The application communicates with the mobile device for which we use different constants depending on the message we need to the send to the device. We are currently using integer constants saved up in a module. Eg:

SEND_HI="122"

As the application has grown and we have around 50+ constants we are realizing that this is a bad way to handle constants as different developer seems to give different constants and clashes occur. Also there is a mismatch between the constant values in ROR and sinatra (due to developers mistake obviously). What is a pain free way to handle constants or message identifiers.

Answer 1

Well, first of all, you should probably avoid storing all your constants in the same place. If you have two different services you should use two different modules to store them. Place them as submodules if you like, e.g. Constants.Ror and Constants.Sinatra. Logically separating the two will help avoid naming clashes and make it easier to find which constants apply for what service.

I'm not very familiar with Ruby. Does it have an enum structure? Since you are using integer constants (which I assume would be unique), an enum would be ideal for preventing constant conflicts.

Answer 2

The two big techniques in this area are namespace management and "single-source-of-truth".

The basic idea of namespace management is to have a hierarchy of naming so that the name of a constant make it clear what part of the system it relates to, and what it's for. In C++ for example, this is done with the "namespace" keyword, while in Python and Java this is done via class and module names.

Single-source-of-truth is a technique for managing shared constants across different implementation languages. The idea is that you maintain the master values for a specific category of constants in a single file. This file is then processed by your build system to generate as output a definition in each implementation language in your wider system. This means that there's a single place for maintaining these, and (say) the C header file which the C-based part of your system includes to get the values of the constants is never checked in to the version control system. There is only one place to update the value of a constant, or add a new related constant.