Question: I have a disagreement with one of my colleagues on whether or not functions should have inverse functions available.

I would like to know when/if inverse functions should be used.

For example, say we have a function `isTrue(boolean condition){return condition == true;}` then what I would do is also include a `isFalse(boolean condition){return !isTrue()';}` function, given that I know that `!isTrue()` is used in the code-base.

I argue that this makes the code more readable and less error-prone as you may forget to add the "!" (which has happened to me on occasion).
He argues that the function is superfluous as `!isTrue(condition);` is functionally equivalent to `isFalse(condition)` and therefore `isFalse()` should not be included in the API of the class.

Clearly he is right about them being functionally equivalent but I disagree that this means you should not include the `isFalse()` method.
I believe that I have read somewhere that my version decreases cognitive load but I can no longer find the source. Either way, my take is that "This condition is false" is easier to understand than "This condition is the inverse of true".

If you know of any sources on either my take or his and you can share them that would be appreciated.

Answer: 
```
bool IsLate()
{
  return (Now > DueDate);
}

```

What's the complement method here? `IsEarly`? `IsNotLate`? What if `DueDate` is undefined or null (depending on the language)? Are you going with this implementation?

```
bool IsEarly()
{
  return !IsLate();
}

```

Well no, because you can be not late and not early. You can be right on time. What about this?

```
bool IsNotLate()
{
  return (Now <= DueDate);
}

```

Okay, you've got two methods to maintain now. Does that make sense in your problem space? Is it worth having two things to fix if you need to change the syntax or interpretation of `DueDate` someday?

Bottom line: *Write the code that does what you mean.* If what you mean is "that idea of lateness, do something when it's not happening," that's probably `!IsLate()`. If what you mean is "that idea of being on time or early, do something in that event," that's probably a separate `IsNotLate()` or `IsEarlyOrOnTime()` method. And if the straightforward way of expressing one of those ideas is directly in terms of the complement, okay, do that.

Let the code map to the problem space.
As in many cases, this is context dependent. `IsTrue`/`IsFalse` are contrived examples, but think of real life cases. A collection might have a property `IsEmpty`. It makes sense to ask the question `if (myStuff.IsEmpty) {...}`. Does it make sense to have an `IsNotEmpty` property? Is it any more legible than `!myStuff.IsEmpty`?

I've written such inverse properties before, in contexts where it made sense. In WPF, where you have UI elements whose properties are declaratively bound to object properties, there is value in having it so you can bind `<ListView DataContext="{Binding MyStuff}" Visibility="{Binding IsNotEmpty}">` to show a listview only if there is data in the list. But that's a very specific use case, meant to work around limitations in the framework.

It might make sense in some cases, or feel overly verbose and unnecessary in others. Consult your teammates and code reviewers, reach a consensus and stick to it.