I know many new developers who have learned a singular metric for code quality, and that is the amount of repeated code. The acronym DRY(don't repeat yourself) is repeated frequently.
After having worked on code that was far too DRY in my webdev days, I unhesitatingly believe that this is a poor solitary attribute to emphasize. What do I mean by too DRY?
- Two diverging control flow paths which happen to share the same way of computing a value will be made to merge just to deduplicate that value
- Functions which happen to perform one desired side effect as a result of computing others are used, and the return value discarded or other effects "reversed" somehow.
- An operation repeated between 2-3 branches such as OR-ing a value with a bitmask and printing it will be broken out into it's own function despite the fact that this code fragment *means* nothing in isolation.
Conciseness is all well and good, but a developer ought not try to compress the program he is working on. In making a manual huffman coding of your code, you make it so that all of your hard-won jankiness must be undone in order to edit the code at all. In order to debug it, one-liners must be expanded to print intermediate results and functional approximations to your obfuscation must be made so *those* can be plugged in and debugged instead.
If you've ever tried to make an internal, complex function into an external one in order to achieve a simple mutation of state with it that you already have access to, you are making the next developer's job harder.
Equally as important, you make it as difficult for the compiler to understand what semantics to preserve as the next guy. Your slow code doesn't need more deduplication and more branches, it needs your fast path to be a straight line.
For this reason, I think that estimation of code quality should emphasize things like consistency of design and local understanding over nearly arbitrary considerations such as whether the same string is reversed in multiple diverging paths of control.