Your peer tells you after reviewing the code.
You cannot determine this yourself easily because as the author, you know more than the code says by itself. A computer cannot tell you, for the same reasons that it cannot tell if a painting is art or not. Hence, you need another human – capable of maintaining the software – to look at what you have written and give his or her opinion. The formal name of said process is peer review.
Sometimes, the best way to know, is to come back to code you wrote six months ago and try and understand what it was written to do.
If you understand it quickly – it’s readable.
- maintainable if you can maintain it.
- easily maintainable if someone else can maintain it without asking you for help
- readable if someone else, on reading it, correctly understands the design, layout and intent
The real test for 1. is (as Alex in Paris and quant_dev say) that you can pick it back up after a few months doing something else.
The test for 2. and 3. is that someone else can pick it up, and figure out how to extend or fix your code while following the grain of your design. If they can’t understand the design, how it relates to the problem space, or how your code is intended to be used, they’ll hack a solution across the grain instead.
There are rules of thumb, principles (ie, rules of thumb someone wrote up nicely and gave a name) and all sorts of suggestions that may lead you in the right direction, or away from common pitfalls. None of them will guarantee the qualities you’re asking for, though.