Why to stop writing negative code

Previous research has suggested that including negative words, such as “not,” in the middle of a sentence can throw off our brains and make it more difficult to understand.

As a software programmer, I have noticed that omitting negative operators in the code translates into a more productive code base. In my code reviews, I have encouraged my teams to write in a positive way so it’s easier to understand and work with. This might go against the natural tendency of writing, but it pays off especially as the codebase grows. There are a lot of benefits to writing positive code. In this article, I explain why we should try to avoid negative code as much as possible.

The human mind struggles to understand negative words in statements.

Negative words require more thought. We can think of thoughts as arrows that have a direction. Negations will flip the logic of the thought.

For example

“do NOT feed the animals.”

A famous sign in zoos or parks can be “Do not feed the animals.” Many signs have to emphasize the word “not” to help people remember that part of the statement. Have you noticed that they rarely use the compound verb + negation “Don’t” like Don’t feed the animals”? By separating the negative part it is easier to emphasize. Anyways the mind has to flip the thought.

An easier way to understand could be, avoid feeding animals.

The stop sign is a great example.

Stop communicates a simple straightforward idea. Stop. What if this sign would be rewritten to “Do not Go”? It kind of dismisses the negative part.

Good

“Stop”

Bad

“Do not Go”

Positive statements are easier to understand

Straighten out the logic in a statement so it’s easier to read. Avoid the negations as much as possible since that flips the logic. The human mind has to work more to understand a flip in the logic.

A positive thought is:

  • easier to read
  • easier to peer review
  • pushes the writer to improve reader’s experience

For example, compare the following two statements:

Good

“If I get the money I will pay you.” (OK)

Bad

“If I don’t get the money I will not pay you.” (so… are you paying me or not?)

The first statement is simpler to grasp. Simplicity consumes less thinking power. The benefit is quicker communication and fewer misunderstandings.

Negative code is tricky to understand

Programming languages have logic operators just like mathematics. Many of the most popular programming languages use == for equality and != for negations. In math would be = and ≠.

In the following code example, we want to write an algorithm. The program will look into a groceries store. The instruction is to buy bananas if they are in stock. Otherwise look in another store.

Good

Bad

An example with ternary expressions

Good

Bad

Easier to mess up when negative code adds up

You might think that it’s quicker to just drop in a negative operator while writing code. That soon becomes a habit and suddenly you start writing negative operators everywhere. That can add up to become a very confusing mess.

Let’s say we want to write a program that will recognize a Tesla car.

For this example, I’ll use the logic operators && for AND and || for OR.

Good

Bad

Translates to:

It is not a Tesla if it is not an electric car, and it’s not fast and it’s not awesome.

Our language might be the one to blame

Lera Bododitsky presented in her TedTalk that languages shape the way we think.

One of her examples is about how people will describe bridges. Both Spanish and German relate nouns to genders. In Spanish, a bridge would be masculine “el puente”. The German language also assigns genders to nouns, making “die Brücke” feminine. Hence, Spanish speakers often will refer to bridges with masculine stereotypical adjectives such as “strong” and “long,” while Germans might describe bridges with feminine stereotypes like “beautiful” and “elegant.”

Negative words are part of most languages. The phrases also have them baked in. “If we have them, why not use them?” We are used to adding negations in our sentences as we are used to including them in our thoughts. Then it seems obvious that we will use negative operators in our code.

When to use negative operators?

There are cases when it makes more sense to use a negative operator. Such a case would be when the negation will still be easy to read, only needs to deal with the negative case, and it will take less code to express.

Closing thoughts

Every time I straighten up a logic statement I witness the power of positive code. Simplifying the codebase is a great dev experience that all the team can benefit from. It’s easier to review and maintain. On the other hand, let’s not take this principle as dogma. Negations are a tool that we can use whenever they make sense.

Thanks for reading and let me know if you have any comments about this principle.