Short Abstract Code or Long Concrete Code?

One of the problems I find with writing code which is primarily written to be easy to understand is that abstractions are frequently harder to grasp than concrete code. That leaves you in a dilemma. You can write concrete repetitive boilerplatish code which is harder to maintain but easier to read. Or you could write shorter more abstract code, which avoids duplication and hence is easier to maintain. However more abstract code tend to require a bit more explanation. E.g. of what the main concepts are.

The Case For Comments Over Long Variable Names

As for prefering long descriptive variable names over comments I want to challenge you on that one. Partly because I recently made the case against long descriptive variable names, but also specifically because I am big proponent of writing comments. I feel commenting ones code, is too easily dismissed. People talk of how comments get outdated, unlike code. The argument against comments is that they may get out of sync with what your code does. However that is equally true of variable, function and class names. People frequently modify code to the point where previous names no longer make sense or are directly misguiding its users.

And obstacle I encounter when suggesting we rename poorly named functions is that long time developers are now used to this name and we don’t want to confuse them. Hence poorly written function and class names have a lot more inertia to them than comments. People have fewer objections to updating comments to reflect current reality.

Geek dad, living in Oslo, Norway with passion for UX, Julia programming, science, teaching, reading and writing.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store