5 ms·

Clean Code was one of the first books I read professionally, and I'm glad I did. Since then, I've formed the opinion that "Uncle Bob" sometimes (as in this cas

Clean Code was one of the first books I read professionally, and I'm glad I did. Since then, I've formed the opinion that "Uncle Bob" sometimes (as in this case) takes helpful ideas a bit too far. But I'm still open to correction. Does anyone know of an open source codebase he's written or been a major contributor to? I know he writes a lot about clean code, but I've never seen production code from him.

jdlshore 6y ago
I believe the FitNesse codebase is open source. The core Fit code was written by Ward Cunningham, but the larger code would have been Bob and co.
nojito 6y ago
Clean Code is extremely overrated and it’s hard to get justifications for the recommendations anymore. Pretty sure he hasn’t written prod code in over a decade.
- cjfd 6y ago
  Yes, especially where he goes completely overboard creating extremely small functions. Most of them are, like, 2 lines.... The general point that code should be clean is a good point to make. Writing a whole book about it seems a bit much.
  - nojito 6y ago
    >Yes, especially where he goes completely overboard creating extremely small functions. Most of them are, like, 2 lines.... Yup which is why we have millions of npm packages that do literally one thing.
    - capableweb 6y ago
      Two completely different things. A npm package is a module of code. A function is... A function. Having a lot of small functions is helpful as it builds up a vocabulary in the codebase, so instead of having to understand every single line each time you come across it, you can extract the meaning into a name. What the npm ecosystem is doing is a completely different thing.
      - nojito 6y ago
        Except the vast majority of npm modules are literally one function. There’s no difference between module and function when you see that.
        dunefox 6y ago
        Yes, those are completely different because I do not release small functions that I compose to bigger functions as separate libraries to be pulled in by the hundreds.
        gmfawcett 6y ago
        The parent's claiming a near 1:1 ratio of modules to functions in NPM. What does that have to do with your release process?
      - inertiatic 6y ago
        >so instead of having to understand every single line each time you come across it, you can extract the meaning into a name. Until you really have to understand what is going on, like when you need to fix a bug or refactor. Then suddenly you to deal with the overhead of holding the branches of 20 levels of indirection in your working memory. Also, this assumes the people you're working with are great at naming things. Which, from my experience, is almost no one.
        capableweb 6y ago
        In general, we have higher-level programming languages so we can do just this, hide the complexity under indirection. It's basically the purpose of the languages we tend to use today, otherwise we would all be still using assembly. Your job as a programmer is being able to walk this ladder of indirection up and down until you find what you seek and fix/add/remove whatever. You'll always be dealing with way more than 20 levels of indirection when programming, even with a "hello world" program. If adding two more levels of indirection makes your mental model break down, you might consider upgrading your environment/workflow a bit to support this. Regarding naming I agree with you. Good names are really, really, really hard to come up with. Entire books have been written on how to name things. Doesn't excuse us from trying though, the only way we can get better is by doing.
    - tchaffee 6y ago
      That claim doesn't even pass a simple common sense test: why would Node.js developers be so much more influenced by Bob Martin (of object oriented and Java fame) than developers in other languages? And it's not even entirely true. You can see that the top ten depended upon packages [1] in npm are the opposite of "literally do one thing". They are either full blown libraries like React or collections of related functions. I'm not claiming npm does not have a problem with too many one liner functions. But the most popular packages do avoid this practice, which is encouraging, and sets the bar for what you should do if you want to be at the top. What other motivations could there be for being the author of many very small and popular npm packages when it comes to interviews and internet fame? There are probably a lot more reasonable answers than "influenced by Bob Martin". [1] https://www.npmjs.com/browse/depended https://www.npmjs.com/browse/depended
      - nojito 6y ago
        > But the most popular packages do avoid this practice, which is encouraging, and sets the bar for what you should do if you want to be at the top. https://www.npmjs.com/package/is-promise https://www.npmjs.com/package/is-promise 7 million downloads a week is not "popular" to you? npm is riddled with packages like these.
        tchaffee 6y ago
        > I'm not claiming npm does not have a problem with too many one liner functions. But the most popular packages do avoid this practice, which is encouraging, and sets the bar for what you should do if you want to be at the top. Just put my claim back in context, with an emphasis on the first sentence and you've got your answer.
- leaflord 6y ago
  May I ask what book would you rather recommend? While I do think that Bob goes overboard with his suggestions in Clean Code, I found it as a necessary counterbalance to encourage readable code in my team, where the methods tends to be gigantic blobs. I'm sure there are better books, but it was a good one. For instance, one suggestion I did like from Clean Code is to separate exception handling from business logic. I don't always practice it, but it really helped in making my work-related code more readable.
wglb 6y ago
Unclear if he has written any major software for long time.
MaurizioPz 6y ago
You can see what look like his contributions to FitNesse here https://github.com/unclebob/fitnesse/commits?author=unclebob https://github.com/unclebob/fitnesse/commits?author=unclebob

jdlshore 6y ago

I believe the FitNesse codebase is open source. The core Fit code was written by Ward Cunningham, but the larger code would have been Bob and co.

nojito 6y ago

Clean Code is extremely overrated and it’s hard to get justifications for the recommendations anymore. Pretty sure he hasn’t written prod code in over a decade.

cjfd 6y ago
Yes, especially where he goes completely overboard creating extremely small functions. Most of them are, like, 2 lines.... The general point that code should be clean is a good point to make. Writing a whole book about it seems a bit much.
- nojito 6y ago
  >Yes, especially where he goes completely overboard creating extremely small functions. Most of them are, like, 2 lines.... Yup which is why we have millions of npm packages that do literally one thing.
  - capableweb 6y ago
    Two completely different things. A npm package is a module of code. A function is... A function. Having a lot of small functions is helpful as it builds up a vocabulary in the codebase, so instead of having to understand every single line each time you come across it, you can extract the meaning into a name. What the npm ecosystem is doing is a completely different thing.
    - nojito 6y ago
      Except the vast majority of npm modules are literally one function. There’s no difference between module and function when you see that.
      - dunefox 6y ago
        Yes, those are completely different because I do not release small functions that I compose to bigger functions as separate libraries to be pulled in by the hundreds.
        gmfawcett 6y ago
        The parent's claiming a near 1:1 ratio of modules to functions in NPM. What does that have to do with your release process?
    - inertiatic 6y ago
      >so instead of having to understand every single line each time you come across it, you can extract the meaning into a name. Until you really have to understand what is going on, like when you need to fix a bug or refactor. Then suddenly you to deal with the overhead of holding the branches of 20 levels of indirection in your working memory. Also, this assumes the people you're working with are great at naming things. Which, from my experience, is almost no one.
      - capableweb 6y ago
        In general, we have higher-level programming languages so we can do just this, hide the complexity under indirection. It's basically the purpose of the languages we tend to use today, otherwise we would all be still using assembly. Your job as a programmer is being able to walk this ladder of indirection up and down until you find what you seek and fix/add/remove whatever. You'll always be dealing with way more than 20 levels of indirection when programming, even with a "hello world" program. If adding two more levels of indirection makes your mental model break down, you might consider upgrading your environment/workflow a bit to support this. Regarding naming I agree with you. Good names are really, really, really hard to come up with. Entire books have been written on how to name things. Doesn't excuse us from trying though, the only way we can get better is by doing.
  - tchaffee 6y ago
    That claim doesn't even pass a simple common sense test: why would Node.js developers be so much more influenced by Bob Martin (of object oriented and Java fame) than developers in other languages? And it's not even entirely true. You can see that the top ten depended upon packages [1] in npm are the opposite of "literally do one thing". They are either full blown libraries like React or collections of related functions. I'm not claiming npm does not have a problem with too many one liner functions. But the most popular packages do avoid this practice, which is encouraging, and sets the bar for what you should do if you want to be at the top. What other motivations could there be for being the author of many very small and popular npm packages when it comes to interviews and internet fame? There are probably a lot more reasonable answers than "influenced by Bob Martin". [1] https://www.npmjs.com/browse/depended https://www.npmjs.com/browse/depended
    - nojito 6y ago
      > But the most popular packages do avoid this practice, which is encouraging, and sets the bar for what you should do if you want to be at the top. https://www.npmjs.com/package/is-promise https://www.npmjs.com/package/is-promise 7 million downloads a week is not "popular" to you? npm is riddled with packages like these.
      - tchaffee 6y ago
        > I'm not claiming npm does not have a problem with too many one liner functions. But the most popular packages do avoid this practice, which is encouraging, and sets the bar for what you should do if you want to be at the top. Just put my claim back in context, with an emphasis on the first sentence and you've got your answer.
leaflord 6y ago
May I ask what book would you rather recommend? While I do think that Bob goes overboard with his suggestions in Clean Code, I found it as a necessary counterbalance to encourage readable code in my team, where the methods tends to be gigantic blobs. I'm sure there are better books, but it was a good one. For instance, one suggestion I did like from Clean Code is to separate exception handling from business logic. I don't always practice it, but it really helped in making my work-related code more readable.

wglb 6y ago

Unclear if he has written any major software for long time.

MaurizioPz 6y ago

You can see what look like his contributions to FitNesse here https://github.com/unclebob/fitnesse/commits?author=unclebob https://github.com/unclebob/fitnesse/commits?author=unclebob