DEV Community

Discussion on: 10 practices for writing readable code

Collapse
 
alexm77 profile image
Alex Mateescu

It sometimes just is.

You can have something as simple as:

return x / 3;

and in the absence of a comment you can't tell whether that was supposed to divide by 3 or by anything else.
Of course, in this particular case you can use a suitable method name and not use a magic number. But I think you get my drift, sometimes the business logic itself is not self-explaining (i.e. explaining why a null check is present where it's not obvious why and whatnot).

Thread Thread
 
ashleyjsheridan profile image
Ashley Sheridan

A good rule of thumb is to comment about the 'why' and not the 'how' or 'what'. This means that the comments that are left are the ones that aren't obvious from the code.

Of course, as with anything there are exceptions, such as dealing with magic values from external sources or one that I've had to do recently: comment what a series of regular expressions were doing!

Thread Thread
 
alexm77 profile image
Alex Mateescu • Edited

Another favourite of mine is when the production code has checks for something that's injected only for tests. To add insult to injury, those tests are usually called... wait for it... unit tests!

Otherwise, yes, that looks like a sensible rule.