3 ms·

I'd say Clean Code is teaching many bad-practices. Too many to be recommended.

by flossly 2mo ago

pixlmint 2mo ago
eh, when I read it as a newbie it was really helpful. still had to make my own experiences and judgments, but overall I think reading it made me a better programmer
- flossly 2mo ago
  at bast it makes to better at "Clean(TM) OOP code". programming in general is waaaaaay bigger than what the book covers.
  - pixlmint 2mo ago
    you realize reading books isn't a zero-sum game right? I can still read more books, it didn't end with Clean Code
    - flossly 2mo ago
      and hence i scope it's message to "clean OOP code"; simply to show that it's flawed message does not even pertain to code in general.
  - Jtsummers 2mo ago
    > programming in general is waaaaaay bigger than what the book covers. It's way bigger than any book covers. Clean Code has some useful things, but if anyone actually reads chapter 1 they'd see that Martin even addresses the idea that you should not just read Clean Code and use it alone, or even entirely. It's a collection of one person's judgements (some good, some bad), just like all the other books like it.
general1465 2mo ago
> Functions should be small + Functions should do one thing This is often a trap for performance. Sure, it looks nice on a screen but calling a function to return a variable is usually epic waste of performance unless compiler will save you by inlining the function into your code or architecture you are using has a magic instruction for that (call vs fcall - which compiler has to recognize and use) which is just fancy "goto there, mov r1 <- *var, goto back"
- bluGill 2mo ago
  If your compilers is any good it will inline, and do a better job than you of figuring out what should be inlined. For that matter function calls are generally fast so long as the objects you copy as part of the function call are not slow to copy (which they can be). There are exceptions to the above, but in general small functions are not a problem. What is a problem is large functions. I have seen functions that were over 60,000 lines long (and few comments or other excess space takers). I will take a 5 lines max rule for functions (this is nearly straw man levels of short!) over that. Functions that are 50 lines long start to get annoying to read but are not a problem. Even 100 lines functions I can handle. However the extreme of long functions is much worse than the extreme of short.
  - rbanffy 2mo ago
    > I have seen functions that were over 60,000 lines long That can't possibly be from a serious person.
    - Jtsummers 2mo ago
      I've seen 10k+ SLOC functions written in C, and 20k SLOC functions written in Fortran, so it wouldn't surprise me if people created ones as big as bluGill describes. The C was almost always written by EEs who learned that function calls were expensive and so they minimized their use of them (this was their stated rationale, not me guessing). What amused me was that every time I tackled one of those things I'd reduce the line count by 70-90%, and usually at least double performance, by using a bunch of small functions to encapsulate the repeated logic. Compilers inline well, and have for quite some time.
pragmatic 2mo ago
Yes. So all you need to do is look at the code samples. Is the most non-sensical thing I've seen. So of course the junior dev parade thinks it's the gospel. Had a terrible manger who would swear by this book but couldn't code his way out of a paper bag.

I'd say Clean Code is teaching many bad-practices. Too many to be recommended.

by flossly 2mo ago

I'd say Clean Code is teaching many bad-practices. Too many to be recommended.

eh, when I read it as a newbie it was really helpful. still had to make my own experiences and judgments, but overall I think reading it made me a better programmer

flossly 2mo ago
at bast it makes to better at "Clean(TM) OOP code". programming in general is waaaaaay bigger than what the book covers.
- pixlmint 2mo ago
  you realize reading books isn't a zero-sum game right? I can still read more books, it didn't end with Clean Code
  - flossly 2mo ago
    and hence i scope it's message to "clean OOP code"; simply to show that it's flawed message does not even pertain to code in general.
- Jtsummers 2mo ago
  > programming in general is waaaaaay bigger than what the book covers. It's way bigger than any book covers. Clean Code has some useful things, but if anyone actually reads chapter 1 they'd see that Martin even addresses the idea that you should not just read Clean Code and use it alone, or even entirely. It's a collection of one person's judgements (some good, some bad), just like all the other books like it.

general1465 2mo ago

> Functions should be small + Functions should do one thing This is often a trap for performance. Sure, it looks nice on a screen but calling a function to return a variable is usually epic waste of performance unless compiler will save you by inlining the function into your code or architecture you are using has a magic instruction for that (call vs fcall - which compiler has to recognize and use) which is just fancy "goto there, mov r1 <- *var, goto back"

bluGill 2mo ago
If your compilers is any good it will inline, and do a better job than you of figuring out what should be inlined. For that matter function calls are generally fast so long as the objects you copy as part of the function call are not slow to copy (which they can be). There are exceptions to the above, but in general small functions are not a problem. What is a problem is large functions. I have seen functions that were over 60,000 lines long (and few comments or other excess space takers). I will take a 5 lines max rule for functions (this is nearly straw man levels of short!) over that. Functions that are 50 lines long start to get annoying to read but are not a problem. Even 100 lines functions I can handle. However the extreme of long functions is much worse than the extreme of short.
- rbanffy 2mo ago
  > I have seen functions that were over 60,000 lines long That can't possibly be from a serious person.
  - Jtsummers 2mo ago
    I've seen 10k+ SLOC functions written in C, and 20k SLOC functions written in Fortran, so it wouldn't surprise me if people created ones as big as bluGill describes. The C was almost always written by EEs who learned that function calls were expensive and so they minimized their use of them (this was their stated rationale, not me guessing). What amused me was that every time I tackled one of those things I'd reduce the line count by 70-90%, and usually at least double performance, by using a bunch of small functions to encapsulate the repeated logic. Compilers inline well, and have for quite some time.

pragmatic 2mo ago

Yes. So all you need to do is look at the code samples. Is the most non-sensical thing I've seen. So of course the junior dev parade thinks it's the gospel. Had a terrible manger who would swear by this book but couldn't code his way out of a paper bag.