[flohofwoe]

IME the 'best' code solves an existing problem with the least amount of code, is human-readable, and easy to throw away (instead of being 'future proof').

Of course this 'easy to throw away' will also lead to a slow replacement process of 'good code' (that's easy to replace) with new 'bad code' (that's incrementally harder to replace) and eventually each software project will end up in the same broken mess, no matter how well it started ;)

[pul]

Replace `least amount of code` with `least amount of complexity` and I completely agree!

[danielbarla]

This has been my "go-to" definition for a while, though I'd add a caveat: complexity can be subjective, based on the reader's particular experience or background.

[manmal]

Whenever I use FRP, I'm worried that the code is super maintainable and readable for me, but a hell for a less experienced coder.

[abritinthebay]

Yes, else it ends up as some form of Perl Golf

[flohofwoe]

Yes that's better. The intent was to not have unnecessary code (often happens when when 'cargo-culting' some design pattern).

[hyperpallium]

Make it easy to throw away; you will, anyway (to mix-gurus).

The problem with modules that are easy to throw away is that the hole they leave is not so easily discarded. This negative space traces the module boundary; the interfaces between modules.

The only way to throw away interfaces is to throw away...? Everything. You will, anyway.

[kolme]

"Easy to throw away" sounds to me like high cohesion, low coupling.