How to reduce the WTFs/Minute in Code Review?

One way to improve your code is to reduce the WTFs/minute when someone else (or yourself) review the code.

Good code is not just a working code that machines can execute efficiently. Good code is also a working code that humans can read and understand. A famous comic of Thom Holwerda nailed it in the subject. You can distinguish good and bad code according to the WTFs per minute expressed in a code review. 

“WTF is that?”

“WTF did you do here?”

“WTF is this for?”

Some programmers wrongly think that bad code will make them essential in a company. As they are the only ones available to understand the code, they will be required in the future. However, the truth is that low quality will be a headache even for your future yourself. Being essential is not an asset on vacation days, for example. On the other hand, good quality code eases collaboration and code review.  

Saying that, is there a way to reduce the WTFs/minute for improving your code? Of course, it is! Maintaining a clean code will help future people to continue your work (that future person could be yourself).

You can reduce the WTFs/Minute with following these two key poitns

  • Type checking
  • Naming

Do Type Checking

Languages such as JavaScript can produce unexpected outputs due to they are weakly typed. Nowadays, there are ways to resolve these problems successfully with strong type checks. For example, in JS, it’s a good practice to use ‘===’ instead of ‘==’ for avoiding common problems of the language.

// example

const value = "500";
if (value === 500) {
    console.log(value);
// it will not be reached
}

if (value === "500") {
    console.log(value);
// it will be reached
}
Weak types may be a headache.

Give variables and functions descriptive names

Name a variable as x is good for math books, but it’s a terrible idea for coding most of the time. A good practice is naming variables in ways that reveal their intention. Doing that give some advantages when reviewing and refactoring the code: they’re more searchable and easier to understand after a person sees them.

// Bad code

x = 'apple'

// Good code

fruit = 'apple'

Your variable names should be short enough to type fast, but long enough to be understood. As a recommendation, length can be 1 char for loop counters, 1 word for condition/loop variables, 1-2 words for methods, 2-3 words for classes, 3-4 words for globals.

Procure to use specific names for variables. Naming variables such as”value”, “equals”, “data” is not a good idea in most cases. Instead of that, use meaningful names for variables. A variable name must define the exact explanation of its content.

// Bad code

value = 7.5

// Good Code

price = 7.5

You can check here an example of rules to name variables.

What else can you do to reduce WTFs/Minute?

Other good suggestions to reduce WTFS/Minute are to keep your code simple and follow the DRY (Don’t Repeat Yourself) principle.

It’s easier to request for simplicity than do it, as this discussion in StackOverflow reveals. Between the recommendations for code simplicity are strong data types, prefer clear code that commenting, Also, it’s suggested to periodically refactor your code to do it in simpler ways.

Read also: How to create tests in Ruby on Rails? (Part 1)

The issue of illegal mobile phones in South Africa

The issue of illegal mobile phones in South Africa

Illegal mobile phones in South Africa clog mobile networks and lead to loss of revenues from the government’s VAT, so how can this issue be fixed to relieve legit mobile users and increase the state’s revenue?

The issue of illegal mobile phones in South Africa

The issue of illegal mobile phones in South Africa

Illegal mobile phones in South Africa clog mobile networks and lead to loss of revenues from the government’s VAT, so how can this issue be fixed to relieve legit mobile users and increase the state’s revenue?