Software Development

Stop Writing Comments

This should go without saying, but it doesn’t. We should treat a comment as though it’s a danger signal. A comment is either an admission of failure, or a warning about the unexpected.

In Talking Around Your Docs, I looked at how it used to be fashionable to explain every line of code.

I’ve also warned about Herp Derp and Cruft in Tests. All of which is about making what should be familiar things, long winded and overwrought.

Maybe if we defaulted comments to flashing red, people would use them more wisely!

Documentation is Good

API documentation, read inline with the code, and published out to API sites, is good! It’s versioned with the code; it’s right there; it explains the semantics around using that code. That’s got to be useful, right?


What the HELL is THIS!?

//message bytes
byte[] messageBytes = getMessageBytes(theMessage);

The above is an example of a nervous tic. Filling a comment because we somehow need to sacrifice some screen space to the gods.

Would it be better like this?

// the message converted into bytes
byte[] messageBytes = getMessageBytes(theMessage);

No. Because the variable name should spell out what’s going on.

A lot of comments we write are no better than this!

When to write line by line comments

When I’m writing in an unfamiliar, or non human readable language, then I may choose to explain what the code is doing for the unwary.

This is probably in the category of an admission of failure. The truth is that I don’t really speak bash scripting, and my javascript is fine, but some of the constructs seem instantly forgettable:

return => regex.match(val))
    .filter(x => x)
    .map(match => match[0])
    .filter(x => x)

The above is valid code, but perhaps a little more obscure than the equivalent well-named methods in Java… and perhaps it would be overwrought to use explanatory functions, especially where the filter is concerned.

Can I be forgiven for:

// compare with path pattern
return => regex.match(val))
    // remove non matches
    .filter(x => x)
    // convert to capturing group for customer
    .map(match => match[0])
    // remove falsy customers
    .filter(x => x)
    // use the unique algorithm to dedupe

Maybe the above is helpful in terms of comment, but it’s no way to live your life.


Code is a language and should express itself. Sometimes our books have footnotes or asides in them to explain the text, and perhaps that’s useful occasionally in code. But it can’t be the norm.

In rare cases, it may be forgiven though… unless it’s saying nothing.

Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: Stop Writing Comments

Opinions expressed by Java Code Geeks contributors are their own.

Ashley Frieze

Software developer, stand-up comedian, musician, writer, jolly big cheer-monkey, skeptical thinker, Doctor Who fan, lover of fine sounds
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Newest Most Voted
Inline Feedbacks
View all comments
bubble shooter
4 years ago

forgive them, some people does not know what they are saying and sometimes their hands is faster than brains

Back to top button