The best programs are programs that behave exactly as a programmer, just by reading its source, would expect them to. From the source, it should be easy to ascertain:
- runtime and space complexity,
- where and why an error occured.
But in the real world, deadlines happen, and harried programmers write and commit just about anything that seems to work.
All the same, a program which cannot be deduced to be doing the right thing (correctness), by inspection of its source, is at best a black box, and at worst a liability. If you want to make software that works, and you know it, I believe that you have to value obvious correctness over anything else.
Obviously correct code is focused
Without focus, a piece of code cannot be said to be obviously doing anything in particular. Focus is about identifying what the code doesn't need to do, then not doing that.
Can your program be expressed with simpler machinery? Do you really need a class, when a function will do?
Are the future needs of your code complicating the way that your code is written today? Are those needs not going to change over time or as you understand the problem better by writing more code?
Obviously correct code is brittle
If your code is brittle against its assumptions, it'll fail right away if anything is wrong. It's easier to understand, trace through, and feel confident in code written like this, because there is a narrower range of acceptable state as the program runs.
If a function gives you an error code, do something with it. If you're in a language where a function call could throw an exception, catch every kind of exception it could throw separately.
assertstatements whereever you believe something to be true about a value but aren't sure.