How to name boolean "flags"?

Question

C++ / C#

Hello.
A lot of letters about a very small problem ;)
In the process of discussing one problem with colleagues, I had a cognitive dissonance.
Briefly speaking. We have a project. A project is a lot of someone else's code, to which we attach a little bit of our own code.
When we add our code, we enclose it:
#if BUILDFLAG (ENABLE_OUR_KILLER_FEATURE_X)
Well, if necessary, include this piece of code in the most important header:
#define ENABLE_OUR_KILLER_FEATURE_X 1
However, sometimes you need to *disable* already existing foreign features.
I suggested that it would be better to set the DISABLE_THEIRS_CODE flag.
And frame someone else's code in #if !BUILDFLAG(DISABLE_THEIRS_CODE).
As a result, "out of the box" someone else's code works, but if you write:
#define DISABLE_THEIRS_CODE 1 ,
then someone else's code will be disabled.
What happened next was fun. Colleagues reared up and said that for *uniformity* it is better to name all flags as ENABLE_X.
But for those (foreign) features that need to be disabled, you just need to write:
#define ENABLE_X 0
The result is that I have cognitive dissonance and the understanding that they offer garbage, and this is not necessary.
The problem is that apart from intuition, I can’t argue my thought with anything. Well, except that "there are two tasks - turn on and off, and the tasks are different."
Any idea why it's bad to use a flag called ENABLE to *disable* features?

Answer 1

Have fun)
The DISABLE flag, if accepted, will explicitly indicate that it wraps around legacy code. A new programmer will come to the team, read this my previous sentence, and will understand without looking into the history of commits that you can ask your colleagues about disabled features, and you will have to rake the disabled ones yourself (

Answer 2

In such cases, you need to weigh all the pros and cons.
What are the benefits of your option? I don't see as a downside that you can get confused about enabling/disabling features.

Answer 3

Since in any case you have to climb into someone else's code and frame something there, a uniform approach will reduce the overall complexity of code perception.
From a psychological point of view, the problem is that you don't want to take responsibility for someone else's code. As soon as you allow yourself to take responsibility for the so-called. "foreign" code, because now it is not a stranger at all, it is yours. it is under your care, you took up its modification, your subconscious will not resist and as a result you will have less inclination to introduce unnecessary entities into the code, and in general the work will go faster. (If you reformulate your proposal: you proposed to bring code separation into the functional level of feature management, depending on the origin of the code. )