Refactor the way we use macros to define well known strings.

[ndp-opendap]

We use a lot of macro definitions to define well known string literals, and this is considered a "high" severity issue by SonarCloud:

This issue has a high impact on the maintainability of your software.
Severities are now directly tied to the software quality impacted. This means that one software quality impacted has one severity.There are five levels of severity: blocker, high, medium, low and info.

Here are their thoughts on why it's an issue and what to do:

A macro is a textual replacement, which means that it’s not respecting the type system, it’s not respecting scoping rules…​ There is no reason not to use a constant instead.

Most of the time, a macro can be replaced by a constexpr declaration (a constant that is guaranteed to be computed during compilation). If your compiler is too old to properly handle constexpr, you may use const instead.

If you have a series of related integer macros, you might also consider replacing them by an enum.

Noncompliant code example

#define MAX_MEMORY 640 // Noncompliant

#define LEFT   0 // Noncompliant
#define RIGHT  1 // Noncompliant
#define JUMP   2 // Noncompliant
#define SHOOT  3 // Noncompliant

Compliant solution

constexpr size_t MAX_MEMORY = 640;
enum class Actions {Left, Right, Jump, Shoot};

But because our current use pattern means that these macros are utilized in multiple files via the #include pattern that may have to change, because doing that with global variables is going to be toxic. Unfortunately there's a lot to consider here.

We need a new pattern that we can apply to this.

[jgallagher59701]

We might want to do this with libdap first to see what weird things happen...

[jgallagher59701]

And to see if we can script this change - as in, can this change be driven by a machine or do we need to think about each instance. The real benefit seems less than some of the other things sonar points out.