You do? I have the opposite experience: I regularly stumple over dirty code where levels of abstraction differ wildly and I regularly lose my train of thought, because some function writeToFile() all of a sudden shifts some bit in a register with an outdated comment next to it (overly dramatizised).
Functions never being longer than 4 lines goes, too far IMHO, but the “clean code should read like prose” bit is something that has been really useful to me.
Functions never being longer than 4 lines goes, too far IMHO,
That’s the problem with the book! People experienced enough to sort out bad advice from it are already experienced enough to have learned the good advice.
Im not saying every word of it is wrong, just that the sum total of all his advice is. I don’t think there’s any school of thought that says it’s good for a function named ‚writeToFile’ to be doing other stuff
My (poorly chosen) example wasn’t about the side effects, but rather about the differing layers of abstraction. Almost all criticisms I’ve seen was about the “functions should be like only 4 lines” rule. Which admittetly: Is a bit whack. But no one actually pulls that rule through, do they?
I think the focus on short, simple functions combined with DRY code leads to many early, poorly chosen abstractions. Getting out from under a bad abstraction can be painful.
But no one actually pulls that rule through, do they?
They do though. Loads of new people to programming read that book and create unreadable messes of a code base that follow all of his advice. I have lost count of the number of times I have inlined functions, removed layers of abstraction and generally duplicated code to get a actual understanding of what is going on only to realize there is a vastly simpler way to structure the code that I could not see until all the layers and indirection are removed. Then to refactor again to remove redundant code and apply more useful layers again that actually made sense.
And that is the problem we have with his book. People that need it take up as many bad habits as they do good ones leading to an overall decline in their code quality. It is not until years of experience that you can understand the bad bits and ignore them. So overall his book is a net negative on the programming world. Not all his advice is bad, but if you can tell that then you likely don’t need his advice.
But on the layers of abstractions specifically, he takes this too far. Largely because of the 4 line limit he has. There is a good level of abstraction and I generally find more than 2 or 3 levels of abstraction is where I start to loose any sense of what is going on. He always seems to jump on abstraction as soon as he can, but I find waiting a while and abstraction when you need to to lead to fewer and vastly better layers of abstraction overall.
And adding more abstraction does not help the people of people doing too many things inside a function - they just move it to sub functions rather than extracting the behavior for the caller to deal with. I have never seen him give advice on what that is appropriate, only keeps the functionality of the original function the same and move the logic into a nested function instead and that only covers up the issue of the function doing too much.
You do? I have the opposite experience: I regularly stumple over dirty code where levels of abstraction differ wildly and I regularly lose my train of thought, because some function
writeToFile()all of a sudden shifts some bit in a register with an outdated comment next to it (overly dramatizised).Functions never being longer than 4 lines goes, too far IMHO, but the “clean code should read like prose” bit is something that has been really useful to me.
That’s the problem with the book! People experienced enough to sort out bad advice from it are already experienced enough to have learned the good advice.
Im not saying every word of it is wrong, just that the sum total of all his advice is. I don’t think there’s any school of thought that says it’s good for a function named ‚writeToFile’ to be doing other stuff
My (poorly chosen) example wasn’t about the side effects, but rather about the differing layers of abstraction. Almost all criticisms I’ve seen was about the “functions should be like only 4 lines” rule. Which admittetly: Is a bit whack. But no one actually pulls that rule through, do they?
I think the focus on short, simple functions combined with DRY code leads to many early, poorly chosen abstractions. Getting out from under a bad abstraction can be painful.
They do though. Loads of new people to programming read that book and create unreadable messes of a code base that follow all of his advice. I have lost count of the number of times I have inlined functions, removed layers of abstraction and generally duplicated code to get a actual understanding of what is going on only to realize there is a vastly simpler way to structure the code that I could not see until all the layers and indirection are removed. Then to refactor again to remove redundant code and apply more useful layers again that actually made sense.
And that is the problem we have with his book. People that need it take up as many bad habits as they do good ones leading to an overall decline in their code quality. It is not until years of experience that you can understand the bad bits and ignore them. So overall his book is a net negative on the programming world. Not all his advice is bad, but if you can tell that then you likely don’t need his advice.
But on the layers of abstractions specifically, he takes this too far. Largely because of the 4 line limit he has. There is a good level of abstraction and I generally find more than 2 or 3 levels of abstraction is where I start to loose any sense of what is going on. He always seems to jump on abstraction as soon as he can, but I find waiting a while and abstraction when you need to to lead to fewer and vastly better layers of abstraction overall.
And adding more abstraction does not help the people of people doing too many things inside a function - they just move it to sub functions rather than extracting the behavior for the caller to deal with. I have never seen him give advice on what that is appropriate, only keeps the functionality of the original function the same and move the logic into a nested function instead and that only covers up the issue of the function doing too much.