Code formatters prevent disputes around code styles, helping pull/merge requests be limited to meaningful code comments. Teams can either agree on a formatting configuration, or use highly-opinionated tools like prettier, which leaves few options open for interpretation.

While this article is focused on inline if statements, the same points can be applied to other missing rules.

Inline example

if (!isAllowed) throw new Error("You do not have permission!");

Nested example

if (!isAllowed) {
  throw new Error("You do not have permission!");
}

Side effects

• Placing a breakpoint is difficult or impossible in some debuggers. A developer could convert to a block statement (which may not always be possible without reloading/recompiling the app), hit the breakpoint outside of the condition, or create a conditional breakpoint — all tedious options.
• **Adding new lines of code in the block is annoying. **If the code added is temporary, there is an extra step to revert the braces.

if (!isAllowed) {
  console.log('User:', user.name);
  throw new Error("You do not have permission!");
}

• The code is harder to read.

“Your thumbs will learn.” — Steve Jobs

The quote was a response to a reporter complaining about a keyless (digital) keyboard on the iPhone.

The same philosophy applies to readable code. When reading through a repository with consistent formatting, the brain will eventually find it readable, regardless if the style is unique.

If the rest of the codebase does not have inline statements, a developer may need to pause to parse the deviation.

Conclusion

Be nice to co-workers, and don’t deviate from the styling in the rest of the repository.

#code-quality #best-practices #clean-code #software-development #debugging