3 ms·

Part of the problem is that nobody agrees what "clean code" looks like. The only objective definition is "code that somebody else can understand as easily as i

Part of the problem is that nobody agrees what "clean code" looks like. The only objective definition is "code that somebody else can understand as easily as if they had written it themselves". Which never happens. Follow good rules of thumb like keeping methods short, reuse code rather than cutting and pasting, and write unit tests (and, of course, use spaces and not tabs). Otherwise, all code is as clean as all other code.

vbezhenar 7y ago
> Follow good rules of thumb like keeping methods short, reuse code rather than cutting and pasting, and write unit tests (and, of course, use spaces and not tabs). Otherwise, all code is as clean as all other code. You can find people who'll disagree with you on every point in this list. So yeah, nobody agrees what "clean code" looks like.
- bluGill 7y ago
  I agree with everything in the list. I have also seen clean code that violates every item in the list. I also have seen bad code that follows every item in the list.
- mumblemumble 7y ago
  FWIW, at least according to Hillel Wayne's summaries of the state of our knowledge on this stuff (www.hillelwayne.com), all three of those have been studied, and the only one that's been shown to be clearly beneficial is unit tests. (Not TDD, mind. It apparently doesn't matter much whether you write tests first or second, just that you write them at all.)
virgilp 7y ago
> 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).

vbezhenar 7y ago

> Follow good rules of thumb like keeping methods short, reuse code rather than cutting and pasting, and write unit tests (and, of course, use spaces and not tabs). Otherwise, all code is as clean as all other code. You can find people who'll disagree with you on every point in this list. So yeah, nobody agrees what "clean code" looks like.

bluGill 7y ago
I agree with everything in the list. I have also seen clean code that violates every item in the list. I also have seen bad code that follows every item in the list.
mumblemumble 7y ago
FWIW, at least according to Hillel Wayne's summaries of the state of our knowledge on this stuff (www.hillelwayne.com), all three of those have been studied, and the only one that's been shown to be clearly beneficial is unit tests. (Not TDD, mind. It apparently doesn't matter much whether you write tests first or second, just that you write them at all.)

virgilp 7y ago

> 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).