undefined | Better HN

0 pointsprpl4y ago0 comments

I personally strive for code that can be read as a sentence, especially in complicated sections of code.

This sometimes leads to weird intermediate variables which might look superfluous, e.g. intermediates like:

foo_has_at_least_1 = len(foo) >= 1

(not a great example, usually it’s a bit more semantics. than that) but later code using those intermediates reads as english, which can reduce cognitive load when reading the code and obviate comments, and preconditions are more readily verified.

It’s literate programming and I prefer that to long comment blocks like those in some of the examples. All that said, it can be hard to get coworkers into such a habit, especially those who feel brevity and abbreviation is a virtue.

0 comments

nijave4y ago

The problem comes not with what the code does but why the code exists in the first place.

The only time I ever feel the need to leave comments is to explain code that doesn't appear to be needed or isn't obvious why it exists. Usually this comes from agreed upon technical debt, short notice requirements with tight deadlines, or some other form of tradeoff.

"We're doing a simple check and throwing an exception here since we have work to introduce a more comprehensive permission system in xyz epic"

or something like

"There's a complicated race condition in xyz so we're doing a simple sleep here since the proper fix involves introducing a distributed lock"

Sure those types of things are cases you want to avoid but unfortunately you occasionally end up there anyway and leaving a short explanation about a compromise is better than ambiguous code that appears to serve no purpose

j / k navigate · click thread line to collapse