3 ms·

I think Uncle Bob is a great read just because he'll challenge some of your opinions and at least forces you to reason against his arguments. You won't have tha

by dep_b 9y ago

I think Uncle Bob is a great read just because he'll challenge some of your opinions and at least forces you to reason against his arguments. You won't have that if you only visit https://swiftisfreakingawesomeblog.com https://swiftisfreakingawesomeblog.com or http://www.igetpaidtolikethislanguage.org http://www.igetpaidtolikethislanguage.org where everybody repeats your opinion. There's not a lot in Clean Code that I wouldn't recommend to most programmers.

halostatue 9y ago
I strongly recommend against reading Clean Code, because it only applies to Java-like languages, and it doesn't really make good advice anyway. It doesn’t even properly apply to C++, and certainly doesn’t apply to languages with different models (like Ruby or Python). Uncle Bob has made a very successful business out of saying things that sound profound, become popular, but are at best the technical equivalent of fortune cookies, and at worst are profoundly bad advice. Seriously, in TypeWars[1], he says “My own prediction is that TDD is the deciding factor. You don’t need static type checking if you have 100% unit test coverage. And, as we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. What’s more, the benefits of that achievement are enormous.” This is so profoundly wrong on so many levels that it isn’t funny. How do you measure coverage? If you’re doing it by lines hit (which is how most dynamic language coverage tools do it), then you’re not getting any sense of how good your boundary conditions or branch coverage is. If you have a better way of measuring coverage (typically branch coverage), then maybe aiming toward 100% is good, but hitting 100% coverage is a complete waste of time. (I aim for ~85% coverage, depending on the code base and how much is boilerplate code.) In Ruby, do you really need a unit test for: attr_accessor :foo If you don’t at least access `foo`, SimpleCov will say that line isn’t covered. You know what? It doesn’t need coverage, because when you write a unit test for that you’re writing a unit test for the language. Unless you’re actively adding “attack tests” to make sure you have all of your boundary conditions covered, and at least know you can abort or recover from an error condition properly, your 100% coverage means absolutely nothing. Property Checks are better for this. Fuzzing and mutation tests matter to help find this. Even static typing (of which I’m not actually a fan, because 15 years with C++ makes it clear that static typing is not that useful in weakly typed languages) can help find certain types of boundary conditions (look to Ada, where if you declare a type as a range 1..100, only values within that range, or variables that can never exceed that range, can be used with that range). And people take Uncle Bob seriously, even when he posts things that are just asinine attacks on people who have taken him to task when he is wrong (which, IMO, is far more often than he’s right). [1] http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.htm...
- dep_b 9y ago
  I read that. I disagree with his opinion. But that's not from Clean Code. And sure the book is about Java but I don't remember it's a great idea to have unreadable names or classes that do a million things in PHP for example. I never program in Java and I'm really happy about that but a lot of principles apply. The unit test zealotism is the part I ignore about Clean Code. But the rest? Most of it is solid advice.
- erik_seaberg 9y ago
  Every type declaration implies a set of unit tests, and needing to actually write them is not better in any way.
- lgunsch 9y ago
  > it only applies to Java-like languages, and it doesn't really make good advice anyway. It doesn’t even properly apply to C++, and certainly doesn’t apply to languages with different models (like Ruby or Python). I disagree strongly. Sure, there are a very few parts that are more relevant to Java. However, the vast majority of the book is easily applied to almost any language. There aren't many languages that don't have variable names, function/method names, modules, etc. Some of the OOP principles wouldn't easily apply to C, or other languages like it, but a lot of the other advice applies easily.

by dep_b 9y ago

halostatue 9y ago

I strongly recommend against reading Clean Code, because it only applies to Java-like languages, and it doesn't really make good advice anyway. It doesn’t even properly apply to C++, and certainly doesn’t apply to languages with different models (like Ruby or Python). Uncle Bob has made a very successful business out of saying things that sound profound, become popular, but are at best the technical equivalent of fortune cookies, and at worst are profoundly bad advice. Seriously, in TypeWars[1], he says “My own prediction is that TDD is the deciding factor. You don’t need static type checking if you have 100% unit test coverage. And, as we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. What’s more, the benefits of that achievement are enormous.” This is so profoundly wrong on so many levels that it isn’t funny. How do you measure coverage? If you’re doing it by lines hit (which is how most dynamic language coverage tools do it), then you’re not getting any sense of how good your boundary conditions or branch coverage is. If you have a better way of measuring coverage (typically branch coverage), then maybe aiming toward 100% is good, but hitting 100% coverage is a complete waste of time. (I aim for ~85% coverage, depending on the code base and how much is boilerplate code.) In Ruby, do you really need a unit test for: attr_accessor :foo If you don’t at least access `foo`, SimpleCov will say that line isn’t covered. You know what? It doesn’t need coverage, because when you write a unit test for that you’re writing a unit test for the language. Unless you’re actively adding “attack tests” to make sure you have all of your boundary conditions covered, and at least know you can abort or recover from an error condition properly, your 100% coverage means absolutely nothing. Property Checks are better for this. Fuzzing and mutation tests matter to help find this. Even static typing (of which I’m not actually a fan, because 15 years with C++ makes it clear that static typing is not that useful in weakly typed languages) can help find certain types of boundary conditions (look to Ada, where if you declare a type as a range 1..100, only values within that range, or variables that can never exceed that range, can be used with that range). And people take Uncle Bob seriously, even when he posts things that are just asinine attacks on people who have taken him to task when he is wrong (which, IMO, is far more often than he’s right). [1] http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.htm...

dep_b 9y ago
I read that. I disagree with his opinion. But that's not from Clean Code. And sure the book is about Java but I don't remember it's a great idea to have unreadable names or classes that do a million things in PHP for example. I never program in Java and I'm really happy about that but a lot of principles apply. The unit test zealotism is the part I ignore about Clean Code. But the rest? Most of it is solid advice.
erik_seaberg 9y ago
Every type declaration implies a set of unit tests, and needing to actually write them is not better in any way.
lgunsch 9y ago
> it only applies to Java-like languages, and it doesn't really make good advice anyway. It doesn’t even properly apply to C++, and certainly doesn’t apply to languages with different models (like Ruby or Python). I disagree strongly. Sure, there are a very few parts that are more relevant to Java. However, the vast majority of the book is easily applied to almost any language. There aren't many languages that don't have variable names, function/method names, modules, etc. Some of the OOP principles wouldn't easily apply to C, or other languages like it, but a lot of the other advice applies easily.