0

As a vendor, we need to ship applications to many clients, and sometimes we need to customize the application for a specific client, for example by enabling or disabling certain features, or setting appropriate defaults for that client.

I've seen that in some open-source projects this is done with this pattern:

#define ENABLE_FEATURE_XYZ 0

#if ENABLE_FEATURE_XYZ
void featureXyzImpl()
{
    ...
}
#endif

void main()
{
#if ENABLE_FEATURE_XYZ
    featureXyzImpl();
#endif
}

Here you turn the feature on or off by defining ENABLE_FEATURE_XYZ to 0 or 1. The benefit is that code that is not needed is not there.

But some colleagues believe that in the real-world, you need to perform customization at run-time by looking at config-file or registry settings, using this pattern instead:

void featureXyzImpl()
{
    ...
}

void main()
{
    if (configFileValue("Enable Feature XYZ") == true) {
        featureXyzImpl();
    }
}

Their reasoning is that it makes it easier to maintain and test the software, because you don't need recompile to enable or disable a feature, you don't need to keep multiple versions of a library or an executable, and you can send only one version to the testers, who can then enable or disable features at run-time.

Is there a guide, or methodology for deciding which one of those methods is better for a given situation? Or should we just choose between them with a coin toss, or out of personal preference?

sashoalm
  • 75,001
  • 122
  • 434
  • 781

2 Answers2

1

If you individually compile your application for each customers system, I would say you can do it as "conditional compilation". Also you should do this if you have some customer groups, and you don't want that anyone could "hack" your program to abuse features he isn't paying for. But in any other case I could imagine there would it also be the better solution to disable it on runtime.

EDIT:

According to your run-time example: This is the only option you have, if you were a 3rd party provider, where the customer had to turn on and of features by himself, and you are just bring onto account what his customers have used.

dhein
  • 6,431
  • 4
  • 42
  • 74
1

I think it depends on how much "sometimes" is. If you enable/disable features by building an individual version for each customer then you carefully need to keep track what you have delivered to what customer since you need to support there special version of the application. When using configuration files the clever customer may have the chance to enable features he did not pay for but maintenance is much easier for you. I would stay with configuration files as long as possible since they are much easier to maintain.

pag3faul7
  • 428
  • 2
  • 7
  • In our case we're pretty much indifferent to whether the user will be able to tweak something. It's not a problem if he is able to. And open-source projects I've noticed use conditional compilation, but they obviously don't do it because they want to restrict their users. May be conditional compilation is more maintainable? – sashoalm Sep 24 '13 at 08:08
  • Conditional compilation is a pain in the ass, maintenance-wise. You do it because you want to ship smaller executable or you don't want malicious users to use features they didn't pay for. – akappa Sep 24 '13 at 08:14
  • @akappa OK, but I've seen a lot of open-source project that use conditional-compilation. What are their reasons for that? – sashoalm Sep 24 '13 at 13:14
  • They usually do conditional compiling to support different platforms (Windows, Linux, Mac, ...) or in the case of libraries to give the user of the library the option to enable/disable features the need or not. The maintainer of such libraries do usually not have to give customer support since they are not selling a product. – pag3faul7 Sep 24 '13 at 14:13