Another month of clean code
Tags: programming, practices, refactoring
Published: 2017-12-19 13:25:35

---
title: Another month of clean code
published: true
description: Another month worth of clean code examples from my weekly tweets.
tags: programming, practices, refactoring
cover_image: https://thepracticaldev.s3.amazonaws.com/i/21sb87l3qafmx0as40cu.png
---
Last month I published [a month of clean code](https://dev.to/gonedark/a-month-of-clean-code-tips-709). Now that another month has gone by I have more examples. For those that [follow me on Twitter](https://twitter.com/gonedark), you may have already seen a few of these.

Nevertheless, this post provides extra detail - more than I can cram into even 280 characters. So here's another collection of my recent "clean code" tweets.

## Removing Comments
In [this tweet](https://twitter.com/gonedark/status/931195727195332608) I challenge you to remove comments. I pushed this long ago in my post on [Removing Comments](https://jason.pureconcepts.net/2015/03/removing-comments/). In fact, I truly feel this single practice put me on the path to clean code.

I since stumbled upon a passage from [Rob Pike](https://twitter.com/rob_pike) which, quite effectively, summarizes this viewpoint perfectly:

> [comments are] a delicate matter, requiring taste and judgment. I tend to err on the side of eliminating comments, for several reasons. First, if the code is clear, and uses good type names and variable names, it should explain itself. Second, comments aren’t checked by the compiler, so there is no guarantee they’re right, especially after the code is modified. A misleading comment can be very confusing. Third, the issue of typography: comments clutter code.

To emphasize these three points consider the following code _before_ removing comments:

![Code before removing comments](https://thepracticaldev.s3.amazonaws.com/i/21sb87l3qafmx0as40cu.png)

While there is nothing technically wrong with this code, I have drawn out several examples where comments don't hold value. When compared to the same code _after_ removing comments we expose the opportunities for cleaner code.

![Code after removing comments](https://thepracticaldev.s3.amazonaws.com/i/7etjlkbb33spb5oks8be.png)

For me, removing comments is not necessarily about achieving the mythical _self-documenting code_. More that my experience has shown me comments rarely benefit the code in-and-of-themselves. Pushing myself to limit their use or remove them completely has always yielded cleaner code.

{% twitter 931195727195332608 %}

---

## Dead Code
In [this tweet](https://twitter.com/gonedark/status/933363670494666752) I touch upon a similar topic of _dead code_. While comments are one form of dead code, there are many more.

![Examples of dead code](https://pbs.twimg.com/media/DPP4S7kW0AA_Xph.jpg:large)

Dead code can be dismissed as not having an impact on the code. But nothing can be further from the truth. Not only does it disrupt the flow of future readers, but it may also affect their decisions. Over time, this can rot a codebase.

A static analysis tool or linter can go a long way to help identify dead code. Take an afternoon to run one and start removing dead code systematically - in separate commits that can be easily referenced and reverted in the event the code was not truly dead.

{% twitter 933363670494666752 %}

---

## Symmetry
In [this tweet](https://twitter.com/gonedark/status/936275444420268032) I introduce a higher level principle of _symmetry_. This is definitely more of an art form than my other tips. One that may take a long time to implement in code.

Nevertheless, symmetry is best shown by example.

![Examples of code symmetry]
(https://thepracticaldev.s3.amazonaws.com/i/conaag68upn4u4is1mhc.png)

It's important code symmetry appears throughout all aspects of the code - not just its structure. Symmetry should appear in names, format, syntax, even patterns. Truly symmetrical code is the cleanest code.

{% twitter 936275444420268032 %}

---

## Reasonable Returns
In [this tweet](https://twitter.com/gonedark/status/938793333526163457) I focus on return values. Using a _reasonable_ return value can prevent writing code for checking or validating these values.

![Examples of using reasonable return values]
(https://pbs.twimg.com/media/DQdDPMhUEAAX5_y.jpg:large)

Determining a value may seem challenging in the moment. Often, the process of elimination helps. Let data types, method names, or related code guide your decision. In the end, unless your language handles `null` gracefully, any other value is a more reasonable choice.

{% twitter 938793333526163457 %}

---

## Naming things is ~~hard~~ easy
In [this tweet](https://twitter.com/gonedark/status/941340185287102469) I share a few ways to make naming things a little easier. I touched upon the practice of naming things in my first post on [writing clean code](https://dev.to/gonedark/writing-clean-code). These examples help demonstrate that practice in the real world:

![Code sample for naming things]
(https://thepracticaldev.s3.amazonaws.com/i/nw9no6uibrqzitpeazhx.png)

In the end, I try to balance the name with the role. When naming a variable within a limited scope, I often use a short, common name. When naming an object referenced throughout the system, I often use a thesaurus to find a more contextual name. 

{% twitter 941340185287102469 %}

---

_**Want more cleanup tips?** [Follow me on Twitter](https://twitter.com/gonedark) to get weekly tips, code tweets, and other randomness._