Is it better to do this

#define INT_TRUE 1
#define INT_FALSE 0

int someFunctionalityIsEnabled = INT_TRUE;

or this?

int someFunctionalityIsEnabled = 1;

It can be safely assumed that false will always be zero and true will be non-zero.


2 Answers 2


It can be safely assumed that false will always be zero and true will be non-zero.

In this case, your question is almost pointless: If you are sure that everyone reading your code knows how "true" and "false" are represented as numbers, then you might not need those #define macros.

Positive side effect of these #defines. I am saying "almost" because these #defines still have value: Without names like TRUE and FALSE, choosing sensible variable names becomes somewhat more important. For example:

int is_enabled = 1;
int age_in_years = 1;

How can you tell which variable stores a boolean value, and which an integer number? By looking at the variable names. Now, how about this?:

int is_enabled = TRUE;
int age_in_years = 1;

The #defines add some redundancy (besides well-chosen variable names) that helps you recognise the "real" type of those int variables more easily.

For this reason of added clarity, I would recommend using such #defines, or if you are using a C99-conforming compiler, #include <stdbool.h>.

Negative side effect of these #defines. There's also a bad side to declaring a TRUE literal. You are saying that "true" may be represented by "any non-zero integer". Defining TRUE as being equivalent to 1 is therefore inaccurate, since that is only one out of many possible values meaning "true". (FALSE doesn't suffer from this.) This leads to the somewhat absurd consequence that writing is_enabled == FALSE will work as expected, but is_enabled == TRUE might not. There's two ways out of this issue:

  1. DO NOT ever compare boolean values using == or !=. Instead,

    • DO write is_enabled instead of is_enabled == TRUE, and
    • DO write !is_enabled instead of is_enabled == FALSE.
  2. CONSIDER re-defining "true" as "the integer number 1" instead of as "any non-zero integer number". (I would not, since it contradicts how C interprets integers as boolean values... but it's a theoretical possibility.)

I recommend you go with #1 for the reason mentioned.

  • Plus, it cannot be safely assumed that other developers have only encountered 'false will always be zero and true will be non-zero.' That's not true in all languages, so it's really nice to have it declared for those of us who can never remember what flavor of bool we're using now. Commented Aug 14, 2013 at 21:34
  • If in your boolean logic you use (is_enabled) and (!is_enabled), doesn't that imply that true is nonzero and false is zero? Then what is the benefit of having these #define's if the rest of your logic already dictates what values true & false must be?
    – Adam S
    Commented Aug 15, 2013 at 16:25
  • @AdamS: For instance, TRUE and FALSE may still be useful when initializing or re-setting variables: is_enabled = FALSE; is simpler than having to write, is_enabled = is_enabled && !is_enabled;, and is_enabled = TRUE is simpler than is_enabled = is_enabled || !is_enabled;
    – stakx
    Commented Aug 16, 2013 at 0:01
  • Right, but why not just do is_enabled = 1 instead of is_enabled = TRUE?
    – Adam S
    Commented Aug 17, 2013 at 0:16
  • @AdamS: Read the first part of my answer again: because of the added redundancy.
    – stakx
    Commented Aug 17, 2013 at 8:57

The result is the same. Using the

#define TRUE 1 
#define FALSE 0 

is more verbose, but it may make your code more readable for future generations (of programmers or your own brain cells) who are maintaining the application and trying to decipher the code.

  • Is using an enum an alternative? (It's been too long since I've coded in C) Commented Aug 14, 2013 at 17:04

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.