You choose

[PhilOfPerth]

Looking at the original post, I'd have to say:

1) I'm with Rho.  Just use _True and _False.  They're built in the language now.

2) If one has to define a value themselves, then I prefer either of the first two methods.  In basic True is always NOT FALSE, but FALSE isn't always NOT TRUE.

FALSE is *only* NOT TRUE when True is -1, but BASIC considers any non-zero value to be True.

2 is True.  NOT 2 is.. -3.  Which is also True.

0 is False.  That's the only guarantee BASIC makes.  Saying True = NOT FALSE will always be correct.  Thinking FALSE = NOT TRUE is only correct in the limited scope of *IF TRUE = -1*.  When dealing with CONST, there's nothing wrong with writing it as your third example does, with the exception that it reinforces the concept that False = Not True, which isn't a true statement all the time.

If one is going that route, then they could probably just use FALSE = _NEGATE True.  Then that statement would always be valid and correct.

2 = True.  _NEGATE 2 = 0.  Which is, indeed, False.

A subtle difference, but one that I think if someone learned to adapt to, it might save them some issues later down the road.  NOT TRUE can still sometimes be TRUE, but _NEGATE TRUE will always be FALSE.

Pardon? 
As someone famouser than me once said, "what is truth?" (no, I don't think it was Trump).

[Ikerkaz]

I prefer number 1.

BTW, I didn't know that _TRUE and _FALSE are in QB64 now... I will use them from now

[bplus]

I prefer 0 and -1, less typing.

[eoredson]

Amazing boolean comparisons. Now try this:

Code: (Select All)

Const false = 0
Const true = -1
z = true Not true

[Pete]

Needs to be written as:

z = true = Not true

That gives z the expected value of zero. The IDE does not pick up the error with z = true Not true but the compiler does.

Pete

[madscijr]

At this point, I just use _TRUE and _FALSE which eliminates 2 lines of code and any guesswork. 

But if we have to define it, I would opt for explicit (#1) 
Const False=0 : Const True=-1

because with 
Const TRUE = Not FALSE

a couple of times I needed to know the value, and I couldn't recall if it was -1 or +1, 
and had to resort to doing a PRINT str$(TRUE) to be reminded, which was annoying.

Really, I am totally happy with _TRUE and _FALSE being natively supported now, so we don't have to think about this stuff!

[bplus]

Is there any advantage of using a Constant over a hard number in this case?

Because I can think of tons where an IF would evaluate to true enough without being = to -1

Code: (Select All)

x = 1
If x Then Print x Else Print "false"
If x = _TRUE Then Print x Else Print "false"

[madscijr]

Yes, the advantage is READABILITY! 

[bplus]

Really we have to spell it out for you? 0 = False

Besides True = -1 does not cover all things Not False and I am sure we don't want to see the list of all things Not False

Perhaps False$ = "" ?

[madscijr]

Really we have to spell it out for you? 0 = False

Besides True = -1 does not cover all things Not False and I am sure we don't want to see the list of all things Not False

Perhaps False$ = "" ?

Making False a string seems like an unnecessary complication.

Is this a debate of preferences or is the QB64PE team looking to do away with _TRUE / _FALSE ? 

Since under the hood, _TRUE and _FALSE are integers -1 and 0, why not just add a simple option to the IDE, a checkbox "Display _TRUE / _FALSE as numbers" and when it's checked, it automatically replaces all _TRUE / _FALSE with -1 & 0 ? The only problem is that it's irreversible - unchecking it, it won't know which -1s & 0s to replace again with _TRUE/_FALSE, LoL. 

Or perhapse under the hood it stores anything that was entered as _TRUE / _FALSE as a special token, so that it can change back & forth? 

Really, I prefer the IDE to let you configure your options so that you can view the code according to your preferences, rather than be forced to endure someone else's. It's like how in C & JavaScript some people prefer the "Egyptian" style of putting the opening curly brace at the end of the previous line and others want it on its own line. I know some people like code to be as stripped down as possible (like C syntax) and others like it more verbose (like Python) but it's 2025, shouldn't we be able to choose our own syntax where our tools "render" the code to our liking on the fly? 

I realize this is a longer reply than you probably expected or wanted but this kind of discussion opens that debate!