I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
I saw no data (aside from his personal experience) or research that supports the positions Uncle Bob expressed in this book. There's no science here. It's all his opinion.
Steve McConnell, on the other hand, cites hundreds of studies in his books.
And I've been at this for 19 years so it's doubtful that he has more than twice as much experience as both of us put together (although I know of no research that says that people who have more experience write better books than people with less experience so I doubt it’s relevant).
Anyway, thanks for reading my post and taking the time to add your thoughts to the discussion.
I wouldn't say it is opinion based, Uncle Bob mentions a lot of other authors in his book.
Design patterns, Solid principles, TDD, code form (class length, function names ect...) by definition ... are not really opinions. They are solid computer software theories and models consolidates over years of computer theories, Uncle Bob just emphasizes them in his way.
I have applied Uncle Bob teaching both at work and on personal project... the benefits have been huge, bug density lower, able to fix problems and scale projects with new feature much faster.
I always advice software developers to leave behind personal biases, be open mind, try, compare with data bases and value experience.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
That's pretty much the definition of opinion. The opinion may be shared widely and have great support among "experts" but that doesn't make it science or fact.
I follow much of Martin's clean code advice. I believe it is effective for my projects. But, again, that's not proof in the same way an engineer can prove that the bridge she is building will not fall down.
For example, in "Code Complete" Steve McConnell reviews the research regarding function length. And the research doesn't support the idea that very short functions are beneficial (as Martin asserts). Now you might take issue with the methods or techniques employed in the research but you at least have something to look at and evaluate. Whereas Martin just says that methods must be short (with no offer of proof).
Theory of relativity is not opinion based, same as gravity, same as computer theory...
Uncle Bob support the Single Responsibility Principle, a function should do one thing and do well, and a long function does a lot of things.
Again you're wrong here, Uncle Bob does just says method must be short, he brings up different examples with charts, comparing bug density of different project (at least in the videos, do not remember in the book).
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
If you did not get that, then is useless we discuss about it.
I am serious on the stuff, the computer theory is an exact science, software patterns and models, are not opinion based, and are proven with years of experience and studies.
I can relate you to thousand of article that says the same thing, function length was just an example swreflections.blogspot.com/2012/12... but I am not going to do that research for you now.
What I am trying to say is that experience and studies have consolidate these things, has nothing to do with opinion based as you say, even you disagree, the best thing to do is to commit to them.
The hardest thing I had to deal in coaching my work teammates, was convincing them that coding using clean code principles was the right thing. Some they were young, unexperienced, other thinking they could write the best code (which only they understand) and the resistance to change thebalancecareers.com/what-is-resi..., are some of the factors you had to deal with, which I think is your case in your article.
And I do not bias you for this, I work everyday with strong opinion based colleagues who thinks "yeah that 1000 line spaghetti code is easy just change that and that"... and loose 7 days on fixing a simple bug, and other 10 trying to extend that code.
I take Uncle Bob for grant, because he has a great experience, he describe exactly what is happening and what will happen in your job, he is not the only one saying those things, and he is basing his writings on theory, studies and solid fundamentals, not on opinion.
And lately especially because I have experienced, tried the benefits of writing clean code.
Again my advice is, be open minded, try, compare, check the benefits, use data and numbers not feelings and opinions.
I saw no data (aside from his personal experience) or research that supports the positions Uncle Bob expressed in this book. There's no science here. It's all his opinion.
Steve McConnell, on the other hand, cites hundreds of studies in his books.
And I've been at this for 19 years so it's doubtful that he has more than twice as much experience as both of us put together (although I know of no research that says that people who have more experience write better books than people with less experience so I doubt it’s relevant).
Anyway, thanks for reading my post and taking the time to add your thoughts to the discussion.
I wouldn't say it is opinion based, Uncle Bob mentions a lot of other authors in his book.
Design patterns, Solid principles, TDD, code form (class length, function names ect...) by definition ... are not really opinions. They are solid computer software theories and models consolidates over years of computer theories, Uncle Bob just emphasizes them in his way.
I have applied Uncle Bob teaching both at work and on personal project... the benefits have been huge, bug density lower, able to fix problems and scale projects with new feature much faster.
I always advice software developers to leave behind personal biases, be open mind, try, compare with data bases and value experience.
That's pretty much the definition of opinion. The opinion may be shared widely and have great support among "experts" but that doesn't make it science or fact.
I follow much of Martin's clean code advice. I believe it is effective for my projects. But, again, that's not proof in the same way an engineer can prove that the bridge she is building will not fall down.
For example, in "Code Complete" Steve McConnell reviews the research regarding function length. And the research doesn't support the idea that very short functions are beneficial (as Martin asserts). Now you might take issue with the methods or techniques employed in the research but you at least have something to look at and evaluate. Whereas Martin just says that methods must be short (with no offer of proof).
Theory of relativity is not opinion based, same as gravity, same as computer theory...
Uncle Bob support the Single Responsibility Principle, a function should do one thing and do well, and a long function does a lot of things.
Again you're wrong here, Uncle Bob does just says method must be short, he brings up different examples with charts, comparing bug density of different project (at least in the videos, do not remember in the book).
Have a look here at lest
softwareengineering.stackexchange....
You serious with this stuff?
You think the ideal length of the function is on the same footing as the acceleration due to gravity being 9.81 meters per second squared?
If you did not get that, then is useless we discuss about it.
I am serious on the stuff, the computer theory is an exact science, software patterns and models, are not opinion based, and are proven with years of experience and studies.
I can relate you to thousand of article that says the same thing, function length was just an example
swreflections.blogspot.com/2012/12... but I am not going to do that research for you now.
What I am trying to say is that experience and studies have consolidate these things, has nothing to do with opinion based as you say, even you disagree, the best thing to do is to commit to them.
The hardest thing I had to deal in coaching my work teammates, was convincing them that coding using clean code principles was the right thing. Some they were young, unexperienced, other thinking they could write the best code (which only they understand) and the resistance to change thebalancecareers.com/what-is-resi..., are some of the factors you had to deal with, which I think is your case in your article.
And I do not bias you for this, I work everyday with strong opinion based colleagues who thinks "yeah that 1000 line spaghetti code is easy just change that and that"... and loose 7 days on fixing a simple bug, and other 10 trying to extend that code.
I take Uncle Bob for grant, because he has a great experience, he describe exactly what is happening and what will happen in your job, he is not the only one saying those things, and he is basing his writings on theory, studies and solid fundamentals, not on opinion.
And lately especially because I have experienced, tried the benefits of writing clean code.
Again my advice is, be open minded, try, compare, check the benefits, use data and numbers not feelings and opinions.
This web site is a great source of examples if you need one:
refactoring.guru/refactoring/smells