A discussion between John Ousterhout and Robert Martin about differences between John's book "A Philosophy of Software Design" and Bob's book "Clean Code". - johnousterh...
I think the rules written in Clean Code are mostly a response to the kinds of bad code that Martin had to deal with. I think compared to the bad examples he cites his rules are an improvement.
Ousterhout mostly pricks holes in these rules, based on the bad code he has seen. But he’s not infallible either since he wrote wrong comments on his own code, which is a bit of a self-own.
I don’t think it’s entirely possible to provide one set of rules that can be universally applied. You need to adjust your code to the problem you’re solving, your audience, your programming language, etc… You’ll always find counterexamples where doing something a little different works better.
Code should be self-explanatory, but a good informative comment can go a long way. Long methods should probably be broken up, but not always and not beyond the point of usefulness. I’ve seen examples where the UB version read better than the JO version, and vice versa.
The value for me in these discussions is finding out why people write what they do, and what they prefer to read (and why). That helps me think about how I can best structure my code for readability. But there’s no point in setting rules and becoming dogmatic about them.
I think the rules written in Clean Code are mostly a response to the kinds of bad code that Martin had to deal with. I think compared to the bad examples he cites his rules are an improvement.
Ousterhout mostly pricks holes in these rules, based on the bad code he has seen. But he’s not infallible either since he wrote wrong comments on his own code, which is a bit of a self-own.
I don’t think it’s entirely possible to provide one set of rules that can be universally applied. You need to adjust your code to the problem you’re solving, your audience, your programming language, etc… You’ll always find counterexamples where doing something a little different works better.
Code should be self-explanatory, but a good informative comment can go a long way. Long methods should probably be broken up, but not always and not beyond the point of usefulness. I’ve seen examples where the UB version read better than the JO version, and vice versa.
The value for me in these discussions is finding out why people write what they do, and what they prefer to read (and why). That helps me think about how I can best structure my code for readability. But there’s no point in setting rules and becoming dogmatic about them.
deleted by creator