> code that somebody else can understand as easily as if they had written it themselves Neah, that's not it. You can write crappy code, as hard to understand b

> code that somebody else can understand as easily as if they had written it themselves Neah, that's not it. You can write crappy code, as hard to understand by others as it is to understand by you - in fact, that's what happens more often than not. It's not that you understand it but nobody else does - it's that in 1month, nobody understands it. The objective definition that I like is "code with no incidental complexity" where "incidental complexity" is as defined by Rich Hickey (see "Simple made easy"). > Follow good rules of thumb Those are not necessarily great rules of thumb, though. There can be too many unit tests, or bad unit tests. And it may be more appropriate to test something at the component level, or integration level. The rule of thumb for a good test is that it should test the business logic as opposed to current implementation. Or that it should not be non-deterministic (e.g. don't test with random data unless you can save the inputs that caused the failure, and reproduce it later; if you can't and just e.g. add a random amount of delay in your tests, it's not a great test).