Four Simple Clean‑Code Rules That Boost Team Productivity

Following these four principles makes our development more solid and enjoyable 😊.

1. Code without tests is bad code

We must continuously strengthen our testing awareness within the team and embed it into our development culture.

Implement unit tests and integration tests to ensure core business logic is sufficiently covered. Insufficient test coverage will eventually let customers discover bugs.

Repeatedly emphasize “code without tests is bad code” until it becomes a basic mindset.

2. Keep methods small

Consider the following example (no need to read it in detail):

function buildUrl(url, options) {
    var queryString = [];
    var key;
    var builtUrl;

    if (url === null) {
        builtUrl = '';
    } else if (typeof(url) === 'object') {
        builtUrl = '';
        options = url;
    } else {
        builtUrl = url;
    }

    if (options) {
        if (options.path) {
            builtUrl += '/' + options.path;
        }
        if (options.queryParams) {
            for (key in options.queryParams) {
                if (options.queryParams.hasOwnProperty(key)) {
                    queryString.push(key + '=' + options.queryParams[key]);
                }
            }
            builtUrl += '?' + queryString.join('&');
        }
        if (options.hash) {
            builtUrl += '#' + options.hash;
        }
    }
    return builtUrl;
};

The code looks long and nested, but it is only 35 lines.

Improved version:

function buildUrl(url, options) {
  const baseUrl = _getBaseUrl(url);
  const opts = _getOptions(url, options);

  if (!opts) {
    return baseUrl;
  }

  const urlWithPath = _appendPath(baseUrl, opts.path);
  const urlWithPathAndQueryParams = _appendQueryParams(urlWithPath, opts.queryParams);
  const urlWithPathQueryParamsAndHash = _appendHash(urlWithPathAndQueryParams, opts.hash);

  return urlWithPathQueryParamsAndHash;
};

function _getBaseUrl(url) {
  if (url === null || typeof(url) === 'object') {
    return '';
  }
  return url;
}

function _getOptions(url, options) {
  if (typeof(url) === 'object') {
    return url;
  }
  return options;
}

function _appendPath(baseUrl, path) {
  if (!path) {
    return baseUrl;
  }
  return baseUrl + '/' + path;
}

function _appendQueryParams(urlWithPath, queryParams) {
  if (!queryParams) {
    return urlWithPath;
  }
  const keyValueStrings = Object.keys(queryParams).map(key => `${key}=${queryParams[key]}`);
  const joinedKeyValueStrings = keyValueStrings.join('&');
  return `${urlWithPath}?${joinedKeyValueStrings}`;
}

function _appendHash(urlWithPathAndQueryParams, hash) {
  if (!hash) {
    return urlWithPathAndQueryParams;
  }
  return `${urlWithPathAndQueryParams}#${hash}`;
}

The refactored code is clearer: the main function is only 14 lines, with short, descriptive names, while helper functions can be examined when needed.

Good habits to adopt:

Plan the core steps of the main function.

Define each core step as a separate helper function.

If a helper becomes complex, further break it down into smaller functions.

3. Methods should have no side effects

Consider the following code and identify its drawbacks:

function getUserByEmailAndPassword(email, password) {
  let user = UserService.getByEmailAndPassword(email, password);
  if (user) {
    // Log user in, add cookie (Side effect!!!!)
    LoginService.loginUser(user);
  }
  return user;
}

Although the function name suggests it only retrieves a user, it also performs a login operation, which is a side effect.

Problems:

The function does two things, confusing callers who expect only a retrieval.

Testing becomes harder because login introduces cookie handling and may require HTTP mocks.

Future maintenance is complicated; separating retrieval and login will likely be needed.

4. Names should have clear meaning

Many developers underestimate naming, but precise, concise names greatly aid maintenance and code reviews.

Avoid vague names like data , foobar , myNumber , or SomethingManager . Such names work at runtime but become maintenance nightmares.

Prefer names that are both accurate and short, enabling quick searches in IDEs.

Conclusion

No‑test code is bad code.

Methods should be small.

Methods should have no side effects.

Names should convey clear meaning.

Content translated and organized from: https://engineering.videoblocks.com/these-four-clean-code-tips-will-dramatically-improve-your-engineering-teams-productivity-b5bd121dd150