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: 
Don’t not avoid negatives. Sure the cpu doesn’t mind them but humans suck at parsing them.

However, the idea that every function should automatically have some complementary function is silly over design if you can’t point to a real need.

Also, `!isTrue()` is not the [inverse function](https://en.wikipedia.org/wiki/Inverse_function) of `isTrue()`. It’s the [logical compliment](https://en.wikipedia.org/wiki/Negation). An inverse function swaps the input and output. A logical compliment negates the output.

Problem is the name `isFalse` is also a negative. It doesn’t add any meaning. You can avoid a `!` by picking the right name. Say, `isOccupied()` vs `!isVacant()`. But that only works when the name has a different meaning on it’s own. It doesn’t help if the name just gives you a negated meaning. It’s far better to use a name that has the correct meaning without needing a negative word attached to it.

So yes, sometimes a good name can avoid a nasty `!` but not all the time. It’s best to talk to your team and find out if this really helps them or not.
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.