> Writing code that is both easy to understand and maintain and correct can be difficult, lots of people just go for the latter.
They believe they go for the latter, but actually they don't. If their code was easy to understand and correct, it would have fewer defects to begin with.
Your second paragraph I totally agree with. I've dealt with such code. Sometimes, I can halve its volume simply by applying local correctness-preserving transformations. That is, without even knowing what the code is doing. I even spotted some bugs in the process.
'correct' is always only about a given specification, that is right for a limited period of time, assuming needs are well understood. It is very well possible to write satisfactory code one day that becomes inadequate the next.
I won't deny the presence of bugs though, there is endless evidence that bugs always exist.
Correct, I was talking mainly about code that 'works' (i.e. is 'correct', for the given spec) but is highly sub-optimal, confusing, tightly coupled with other code, etc...
They believe they go for the latter, but actually they don't. If their code was easy to understand and correct, it would have fewer defects to begin with.
Your second paragraph I totally agree with. I've dealt with such code. Sometimes, I can halve its volume simply by applying local correctness-preserving transformations. That is, without even knowing what the code is doing. I even spotted some bugs in the process.