Code reviews – Part 1

Reading Time: 3 mins

As I read an engaging thread on Twitter about the utility of mandatory code reviews, I realized we have benefited a good deal from code reviews.
Our recommended practice is to have at least two levels of code reviews: one at merge request level and another at pre-deployment level.

Part 1 of the code reviews post will focus on certain key checks that are mostly non-functional.

Passwords in codebase

Connection strings are routinely defined in YAML for database connections with passwords hard-coded.

While this would work locally for one developer it wouldn’t for other developers if the passwords configured are different. Not everyone follows the same conventions for defining passwords.

A good practice is to define usernames, passwords and other connection details as environment variables. Assist those who aren’t familiar with defining them.

Relative URLs

Absolute vs relative URL naming is a common pitfall for developers. While it helps the cause of popular claim (it works on my machine!) it might not necessarily work on testing or production environment.

While such practice is documented one can forget during project execution and fallback to their usual practice (ex: js/helper.js vs .js/helper.js). A developer experienced with production environments can guide the inexperienced members in reviews.

Spaghetti code

In jQuery,  $.get() is a simple to use method to fetch server data. Sequential dependent requests from server quickly spiral the code in to spaghetti mode

$.get('endpoint1', function(response1) {
  // do something with response1
  $.get('endpoint2', function(response2) {
    // do something with response2
    $.get('endpoint3', function(response3) {
      // process
    })
  })
})

There are other approaches that can address this situation well.

Tip – Adopting a coding style guide (ex: Airbnb, Google) for your team will ensure uniform coding standards in the codebase.

Commented unused code

Often we find unused code (or dead code) that’s commented in the hope that we will return to it at some point and re-use it.

This creates a ripple effect where the code permeates through different commits across weeks when someone realizes it’s not being used at all and deletes that block.

A better practice is move the commented code block to a snippet (if using GitLab) or a similar commonplace and refer a link in the codebase. The objective is to keep the codebase light enough.

Comment what’s necessary

We write code not only for ourselves, machines but also for our current and future collaborators. Documenting enormously benefits the team in determining the utility of code blocks. JSDoc is a way technique to document code (within JavaScript files) with support for parameters and return values in functions, creating tutorials and exporting the documentation which can be hosted elsewhere.

// an example of documenting a function - https://jsdoc.app/about-getting-started.html
/**
 * Represents a book.
 * @param {string} title - The title of the book.
 * @param {string} author - The author of the book.
 */function book(title, author) {
}

Output of the exported documentation looks as below:

Storytime.dev is an interesting way to document code but in a story format (play, pause events).

Formatting

Dominantly, we work with Python, JavaScript, HTML, CSS, YAML and follow the default standards (4-space indentation for Python files and 2-space indentation for the rest).

Hide what’s not necessary

Intermediate state values do not reveal much about an application. Defining a variable with lots of default values can be moved to configuration (ex: YAML).

The utility of code reviews will depend on the skill level of the developers an organization employs, focus and bandwidth on training to improve the skills.

In the next part, we will discuss about key functional aspects of code reviews.