He who sacrifices clarity for correctness deserves neither
The unfortunate consequence is that unclear code is rarely correct.
-
-
I think that's a claim that would need to be backed up by a study. Often I've personally found that unclear code is unclear for a reason, such as contorting around a business requirement.
-
The underlying business requirement can be turned into an encapsulating abstraction with a name. Same crappy code, easy to "chunk" in other parts of the code. In a case I'm working on right now, naming the abstraction also provides a good place for a warning about dangers.
-
I don't mean a framework or big abstraction. Just finding a way to get the code out of places it doesn't belong. In these contorted cases, I've often found that compliance is haphazard, but hard to audit because nobody can memorize the full description of the correct behavior.
-
What would be an example of code where making it more clear would compromise correctness?
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.