7 ms·

So like, Clean Code really does say you should write four line functions, and does not put caveats on that statement, Uncle Bob even gives a lengthy terrible-lo

• paulddraper 2y ago
  Uncle Bob sounds good verbally. Like "small functions." I say, okay, okay, stop writing these 2000 lines of spaghetti, I'm a hundred percent on board. Then when you get to the concrete example, it's decomposing this 15 line function. Good idea. Calibration is waaaay off.
• booleandilemma 2y ago
  He's the son of a pastor, he's definitely interested in rhetorical judo.
• icholy 2y ago
  Has uncle Bob actually produced any useful software? Are there any examples of his work out there which can be analysed?
  • tcfhgj 2y ago
    People can give good insight about things despite even not creating these things, see e.g. physicists who study atoms
    • mckn1ght 2y ago
      It’s more like someone who gives talks about smashing atoms to study subatomic particles without ever having been to a particle accelerator facility. You can’t replace experience. There’s theory, then there’s practice. Ideas are worthless until tested in reality.
      • tcfhgj 2y ago
        Oh I think there are plenty experiences out there practicing various strategies of clean code in the wild which he can observe without creating them himself
        • mckn1ght 2y ago
          You really have to experience it yourself to see how the strategies you come up with affect debugging and changing the code when fixing bugs or adapting to new requirements. Things like strictly requiring 4 or less lines per function leads to huge a mess that is very hard to untangle and work with, or even understand for newcomers.
  • theLiminator 2y ago
    Yeah, I get the impression that he just sells his image as some "guru" of software engineering, and that he doesn't actually deal with or write much real life code.
    • buescher 2y ago
      I think the aspirations of the agile manifesto are great, but basically everyone involved in it was an enterprise software methodology consultant. I forget who the exception was; someone will remind me.
  • buescher 2y ago
    He’s got a GitHub. This seems to be the most notable thing: https://github.com/unclebob/fitnessedotorg https://github.com/unclebob/fitnessedotorg
    • pkaye 2y ago
      [flagged]
    • icholy 2y ago
      Seems like this only includes the compiled class files and no actual source?
      • buescher 2y ago
        You’re right. The source is at https://github.com/unclebob/fitnesse https://github.com/unclebob/fitnesse
  • dakiol 2y ago
    Isn’t that the same case for Robert Martin? I’m not going to be the one defending Uncle Bob, but most of the people out there giving advice about “clean code/architecture” come from the consulting world without any work that can be analysed.
    • icholy 2y ago
      Those are the same person
      • dakiol 2y ago
        I always confuse them. I meant Martin Fowler.
    • fishcrackers 2y ago
      [dead]
    • hirvi74 2y ago
      I am rather ignorant of the world of consulting. If someone like Uncle Bob consults a company and the company implement his ideas with his guidance, then is a consultant like Uncle Bob typical gone by the time maintenance rolls around? I ask because I can see his ideas being great to him if he is never around for damage control because what feedback does he truly have that cannot be fought back with some 'Get out jail free' card like "The company deviated from my plan after I left!"
      • bena 2y ago
        Either that or the company hires yet another consultant to rewrite everything because it can't be maintained.
      • seadan83 2y ago
        Clean code had a place and context, it is almost two decades old. The idea of writing usable API's at the time was somewhat novel. Most developers were busy trying to get the code to work at all, that the API was an afterthought. EG: Methods with 3 string variables followed by 4 boolean was not unheard of. Since clean code was written, the two decades since, a number of values are more salient and some novel. Ideas like Single-abstract-method, functional programming, immutable state. Hence, the damage that was being fixed is a swap of convoluted, extremely stateful APIs- to cleaner looking ones, that were more usable, less stateful. (Albeit, Still damaged by modern standards) Things have come along even further since. The ideas in clean code are many, have a context, and were certainly not the final step for programming - which is effectively brand new to humanity. For example, I've been learning to sew recently. Everything I have been learning, except the actual sewing machine, has been known for a couple hundred to couple ten thousand years already. Zero is new. Contrasted to programming, where the first programs are still in living memory - it's a crazy different and new field of knowledge, it is YOUNG. Knowing the context of what was before 2000 imo is critical to contextualize the many ideas in clean code.
  • seadan83 2y ago
    His career IIRC starts in the 70s. After 50 years, the answer is assuredly yes to the first question.
    • Uehreka 2y ago
      It is absolutely possible to code terribly for 50 years and get away with it. Experience is no proof of anything.
      • seadan83 2y ago
        Maybe, but that was not the question. I think that perspective is lacking context as well. Programming has generally gotten better over the last 50 years. It is not a dichotomy of just good code vs bad. Most code is bad, has been bad, and before that was even worse. One could almost view Clean Code as a response to Java Swing - a potential case study of bad API design. I personally greatly appreciate the new focus Clean Code put on API design that was lacking beforehand.
• hirvi74 2y ago
  > I came away feeling like Uncle Bob is more interested in playing rhetorical judo than anything else That's his only option. I am not trying to speak ill of the man, but I am quite dubious of his advice. I truly believe everyone has something to offer. However, I would feel more inclined to follow Uncle Bob's advice if he actually had the portfolio to back it up. If Linus Torvalds were to give advice on how to build an operating system's kernel, I feel as though I should listen. Not only because Torvalds had/has good ideas, but because he also has demonstrable experience and work to back up his claims. Uncle Bob has a lot of words, but projects speak louder.
  • taneq 2y ago
    > If Linus Torvalds were to give advice on how to build an operating system's kernel, I feel as though I should listen. I'm pretty sure Linus' advice is 'don't be r***d'. In recent years he's learned a bit and now also would say 'don't be a c*t, probably, most of the time'. :P
    • hirvi74 2y ago
      You know what? That's still good advice. I think many should take it to heart.
• rileymat2 2y ago
  Perhaps the Uncle Bob principles do not create the best code, or most clear code, but more dogmatic adherence does make it harder to create the code I see on a daily basis that is so much worse and much more unmaintainable.
  • bishop_mortimer 2y ago
    I suppose if the options are "Uncle Bob's Rules" and the straw man of "No Rules" that could be true. That's like if you gave yourself the options of "one hand behind your back" or "two hands behind your back" in a fight when we already knew how to fight with "zero hands behind your back". But I'm not sure I even believe that, because the worst thing is dogmatism. Uncle Bob convinced young developers to be dogmatic. I've dealt with code that was a mess with no adherence to rules. I've dealt with teams where everything need to be perfect. The first group shipped products. The second groups had neat looking code bases but had much more trouble shipping. Sometimes it was impossible to get in simple lines of code because it didn't match "the rules".
• bc_programming 2y ago
  For me, I bought "Clean Code" because it was, at the time at least, quite highly recommended. After being rather confused for a while, I finally stopped reading right around page 141 when I realized that the reason his examples looked awful were because they were. In that section of the book, he takes a Java port of Donald Knuth's PrintPrimes program, and refactors it. But in doing so, he actually breaks it. He moves state out of local variables and parameters and makes them all static fields, and then refactors the code into long-winded methods that specifically perform side effects or operate on those fields (names like isNotMultipleOfAnyPreviousFactor(), isLeastRelevantMultipleOfNextLargerPrimeFactor()). But the simple act of moving state that would otherwise be part of the stack frame into static fields means he has changed the behaviour of the code - it is no longer thread safe! calling it from different threads will have undefined results because all threads will be operating on the static fields. He demonstrably made the code worse!. It invalidated the entire book for me at that point. Here's "Uncle Bob" trying to pretend to be some aged, skilled, craftsman hand guiding us young, ignorant whippersnappers into being proper craftsman and not only can't he properly refactor a simple prime number sieve as a demonstration, but he's so blind to awful code that he doesn't even see it in his awful example enough that it gets published in the same book that complained about programmers who don't have "code-sense". Mistakes and "errata" are one thing, but when he makes such a big noise about "do it right the first time" and then has an example where he refactors and literally breaks something, that's another.
  • Scubabear68 2y ago
    I started reading the code Martin wrote with his son for the “FitNesse” acceptance tracking framework. The code was simply God awful. Nearly every method was tagged ad “throws Exception”, no comments, and the famous endless sea of classes with only a few lines of code per method. The code itself ran with constant exceptions filling up the logs. This was going back over a decade or more when I looked at it. You can see his lineage of trying to sell consulting services and books all the way back to the comp.object Usenet groups back in the 90s. Sadly he still commands big fees to speak at various conferences and companies, I was very disappointed when he spoke at Bloomberg many years ago when I worked there.
  • jrpelkonen 2y ago
• pbw 2y ago
  As the OP, I was not arguing that Uncle Bob's advice is good; I was arguing that performance is not the reason to reject his advice... unless you are counting nanoseconds, in which case performance is a great reason to reject his advice. It's a story of two worlds. Casey lives in a world where nanoseconds almost always count. He says OOP is horrible for performance, but he really means it's horrible for performance in that world. But Uncle Bob's book is about a different world: business Java programming from 10+ years ago. There, the overhead of OOP is almost always negligible. One of my main points in the article was just to be aware of the world you are in. Performance aside, is Uncle Bob's advice good or bad? I think it's a mixed bag. His four main books total 1,552 pages. Some of his advice is rooted in the Java programming world from the 1990s and 2000s, but I think other advice (like "use good names") is valid today in many languages. Sorting through all those pages of advice would require a much longer article; I didn't try to do that; I just tried to address Casey's performance claim, since I think he's totally wrong (in many cases) even while being totally right in other cases.
  • Uehreka 2y ago
    But performance isn’t the reason to reject his advice: common sense and good taste are more than enough of a reason. When he wrote Clean Code, Uncle Bob created a monster. Tons of people hold that book up as the Gospel of how to write not just OOP Java code, but all code. Now is Uncle Bob really to blame for what other people do with the ideas in his book? Absolutely yes. All throughout he writes in a super authoritative tone, snarks at people who disagree with him, and asserts that his 40 years of software engineering experience mean his opinions must be right and that he doesn’t have to explain why. The reaction to his writing is a product of the way he wrote it, and the reaction sucks. In workplace after workplace I’ve had to push back against people trying to sully nice readable code by blindly and stubbornly applying his principles. It’s an endless struggle, one that would be helped if, like Merlin Mann (creator of Inbox Zero) he looked at what was happening and disavowed his creation and spent years working to correct the public’s misconceptions. But Uncle Bob doesn’t want to do that, so here we are.
    • pbw 2y ago
      > But performance isn’t the reason to reject his advice: common sense and good taste are more than enough of a reason. My article and video are responses to Casey's mega-popular video "Clean Code Leads To Horrible Performance," which has 873k views. In it, he falsely claims that clean code always leads to horrible performance when, in fact, it only sometimes does. In my article/video, I explain when OOP/clean code does and doesn't lead to horrible performance. My goal was to debunk Casey's claim since he was factually wrong and continues to mislead people about this to this day. I partially agree with your point that Uncle Bob's advice is wrong for other reasons. His main four books total 1,500 pages. Some of the advice is good, some is dated, opinionated, or just wrong. Untangling all that would require a much longer and very different article, which wasn't the one I was writing.
• bishop_mortimer 2y ago
  In fact, if Uncle Bob really doesn't want 4-line functions, and wants moderation, he should write a better book. Whatever he claims to mean, everyone sure seems to think that's what his book says. I personally found it to be one of the most needlessly dogmatic things I've read.
• wredue 2y ago
  >It is economically better for most organizations to conserve programmer cycles than computer cycles. Yeah nah. At the rate that programs are getting worse, there’s simply no way that this is remotely true now, especially with cloud costs growing quite rapidly.
• seadan83 2y ago
  > So like, Clean Code really does say you should write four line functions, and does not put caveats on that statement This is false. I tried to look this up a few weeks ago, there is no number. The book says (close paraphrase) "functions should be short, and then they should be even shorter than that". It also says, "a function should be only so long that it expresses a single cohesive idea" There is lot of nuance and wiggle room there, and those are not absolutist statements. Reasonable people can disagree whether small talk length functions are good or not, but the characterization of an absolute line limit is false.
  • apocolyps6 2y ago
    I suspect that number comes from this quote a little further down > Every function in this program was just two, or three, or four lines long. Each was transparently obvious. Each told a story. And each led you to the next in a compelling order. That’s how short your functions should be!
    • seadan83 2y ago
      Thanks for pulling the quote. I agree. It is a distinction of "should be" and must be". FWIW: Uncle Bob clarified this exact topic in a recent youtube interview with Primeagen (about 5 months ago). The gist is if the length to have a single cohesive function is 50 lines, then so be it. It was clarified that clean code does not give a hard and fast limit (but does give a very weighty recommendation to go for small functions based on a number of heuristics).