My application is a Java program that controls a robot (which is essentially a raspberry pi hooked up to a lot of devices). There are many devices on the robot that have semi constant address values or pin numbers. Currently in our codebase you'll see a lot of static constants defined like:

static final long SLEEP_DURATION = 100;
static final byte MOTOR_CONTROLLER_ADDRESS = 0x01;
static final byte TOOLING_MOTOR_1_CHANNEL = 15;
static final byte TOOLING_MOTOR_2_CHANNEL = 12;

The problem is that when we're hooking up all the wires in the robot, we might accidentally swap tooling motor 1 and 2. Our current options when this happens are to rewire the robot (time consuming) or recompile the robot code and re-upload it to the robot (also time consuming).

After looking at some libraries I think I could use the Commons Configuration Library to read in a properties file for these values.

final byte toolingMotor1Channel;
final byte toolingMotor2Channel;
    toolingMotor1Channel = config.getByte("motorcontroller.toolingmotor1");
    toolingMotor2Channel = config.getByte("motorcontroller.toolingmotor2");

This doesn't add too much complexity to the code, but it does add some. So my question is:

Does it then make sense to have variables like SLEEP_DURATION or MOTOR_CONTROLLER_ADDRESS be configurable as well? It is possible that these values might be changed in the future, however, it is unlikely. Where do I draw the line with what gets configured from this library?

1 Answer 1


As you yourself stated, if you get into such situations every now and then during your development cycle, it is worth it to make every such variable configurable. The strategy that I use is to define a configurable property with a default, so if the configuration is not found, the default is used. Then start with no properties defined in the file. By doing this, you don't really have to define the configurations unless necessary. Then if you find that some default configuration is not correct, you can always define that property in config properties file to override the default.

Once you are close to stable release, you can decide which of these config properties you want to keep, and which one you want to convert into constants.

  • I like this idea, seems like a simple enough pattern to follow! We currently have command line arguments as well-- to stay consistent perhaps these would also be better in the config file?
    – flakes
    Commented Feb 12, 2017 at 2:09
  • 2
    My general design where there are several/many config items is to have a single command line parameter, which is the name of a config file. Everything else goes in the config file. You can even separate out a default config file, in an implicit location, if you think you may mess with defaults often enough.
    – user103417
    Commented Feb 12, 2017 at 2:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.