[stephc_int13]

I've been writing code for more than twenty years now and I had the opportunity to try many different styles.

It is, unfortunately, very easy to write difficult to read code, especially with good intentions and principles.

In practice, I've found that the most important principle is Locality, that is avoiding nested indirections and unecessary abstractions.

I completely agree with the author of the article here, the simple and dumb recipe with constants local values is both easy to read and easy to maintain.

It might seems like duplication but the complexity has to live somewhere and it is more manageable when it is not scattered.

[Frost1x]

I tend to agree with you, however, there's sometimes so much complexity that you really do have to abstract it to manage sanity.

The issue I often see is that when abstractions are created, the thought process or design of those abstractions aren't well explained. When you create abstractions, more verbose documentation and design is needed to share the ideas. Anyone using this in the future needs to understand your abstractions and there's a cognitive cost of dealing with it.

You reduce this cost when you explain everything well, give examples, show use cases, etc. When you don't provide this sort of verbose documentation, you might as well have made it a large sequential program because it likely would have been easier for the next person to understand.

[stephc_int13]

Yes, this is often more difficult than it seems, this is typically something that requires experience and wisdom.

When unsure, it is still better to write less abstract code and somewhat messy code than falling into the over-engineering trap.

It will cost less to fix and it will also cost less to write in the first place.