15 ms·

It's probably time to stop recommending Clean Code (2020)

202 points by flykespice 4y ago

DotaFan 4y ago
The amount of money I've spared to a companies by first learning the importance of Clean Code before I've tackled projects are immeasurable. Sure, Uncle Bob might be to opinionated and you might not like him, and some coding practices you might not agree with, and are indeed unnecessary today, but rules are important, and this is what we're missing today. Ground set rules, so everyone is on the same page.
- phendrenad2 4y ago
  What's important is that people have the shared language of Clean Code (or some other repository of best practices, could be integrated into your company styleguide, for instance). I.E. If Uncle Bob said "Don't do X" then we can have a conversation in that context if, in this scenario, doing X is acceptable. Without that logical reasoning, people will debate the very existence of "not doing X" as a best practice.
  - DanielVZ 4y ago
    Except having these discussions is really hard. It ends up being you against uncle bob and you are not gonna win that argument against a senior-er engineer.
    - leftbit 4y ago
      Don't think so. If the senior engineer is worth his salt he should know that programming is always about finding a balance between several aspects of a given problem - some of them technical, some of them human. As long as the code does what it's supposed to do the rest is mostly up to personal taste - so yes, you can have an insightful discussion, but there's only to learn, nothing to "win" for all participants.
      - DanielVZ 4y ago
        Yep, but in practice Seniority comes either from experience or time in the industry. So you'll undoubtedly meet seniors that won't try to find that balance.
- leftbit 4y ago
  > but rules are important, and this is what we're missing today. Programming rules are important - they make you think before you break them. Just don't turn rules into dogma - otherwise your devs will be more concerned with following the rules than solving the actual business problems. And you don't want that.
  - DotaFan 4y ago
    You should certainly be flexible around it, visit them every now and then to update. Also, we should enforce them once they are set.
    - leftbit 4y ago
      Really don't like the enforcing. Okay, mixed feelings there. Rules should help you along, perhaps set a framework for your thinking. But they never should limit you in achieving your goal. When establishing a rule you should also specify what you want to achieve by it, how you'll measure its effects and under which conditions it should be removed. Rigid rule enforcement has a strong danger of shifting the priorities of the developers to the detriment of your business.
userbinator 4y ago
A common theme not only in software but other industries: Beware of people selling you advice. They are the ones who will breed dogmatic illogical cargo-cults of people whose only rebuttal when questioned is some variant of "because someone who sold me this book that claims it'll make my code better said so", and that can't be a good thing in general. but we assume that Martin doesn't literally mean that every function in our entire application must be four lines long or less. Unfortunately I have worked (and fortunately, briefly!) with codebases like that --- not surprisingly, in Java. In addition to the complexity of whatever the code is doing, smashing things into tiny pieces also adds its own complexity. The fact that a short function is "easily understandable" on its own, which is what a lot of proponents of this dogma argue, is useless for understanding the functioning of the whole. The latter is far more important when debugging. Function length is ultimately meaningless. I'd rather have a 5000-line function that reads top-to-bottom, than 1000 5-line functions if it means I don't have to jump around several-dozen-level-deep callstacks and try to keep track of 30+ character long identifiers to understand how the thing works.
- rightbyte 4y ago
  Ye flat functions are way underrated. It is so hard to keep track of the call stack when reading code for me. Deeply nested code is read only, unless the problem is nicely modelled as recursive in some way.
  - eurasiantiger 4y ago
    And what kind of problem is nicely modelled as recursive? It’s when your data items have children, which can have children, which can have children...
- tmaly 4y ago
  I had a similar experience. There was a developer in my group that adhered to Clean Code. Four line functions made everything verbose. When he left I had to take over all of his code. The one part of Clean Code that saved my sanity was his choice of names and flow. That made it somewhat easier to navigate. I have experiences with other code where it was so abstract, it took much longer to figure out. I like to go by the rule: "write code for the average developer". I think finding that balance makes it easier to grok the code and maintain it.
bitwize 4y ago
[flagged]
avg_dev 4y ago
Wow this is quite a takedown. For many years I was feeling like I let myself down by not reading the book Clean Code. I now feel like, by accident, I did exactly the right thing. That sample code he quoted is near unreadable to me. I also did enjoy A Philosophy of Software Design; the main thing I took away from it was to avoid unneeded complexity because you want to be able to “spend” your complexity budget for doing actual work.
- DotaFan 4y ago
  Blog is addressing small segment of a book, you might still be missing a good learning. Maybe you can scrim some chapters here: https://dev.to/thawkin3/in-defense-of-clean-code-100-pieces-of-timeless-advice-from-uncle-bob-5flk https://dev.to/thawkin3/in-defense-of-clean-code-100-pieces-...
- rgoulter 4y ago
  I generally liked APoSD. I liked its notion of symptoms of complex code. I liked its framing of complexity as related to dependencies involved in calling some function. -- If a function has more parameters than it really needs (too many dependencies), or a function has fewer parameters than it actually needs, then it's more complicated to work with than it needs to be (its actual dependencies are obscure). -- I liked its emphasis on "interface" is "what you need to know to use the code", as opposed to implementation details. I liked the suggestion of "writing documentation before the implementation" as a way of coming up with a clean interface; although I found it bizarre that this logic didn't carry across to "write some tests before the implementation".
- crucialfelix 4y ago
  If you read the book, understand the principals and then disagree with a few of them, you will have learned more than if you never read it at all.
Octokiddie 4y ago
> Martin states, in this very chapter, that it makes sense to break a function down into smaller functions "if you can extract another function from it with a name that is not merely a restatement of its implementation". But then he gives us: [function that restates its implementation] and [function that restates its implementation] The article's main beef is that Clean Code sets standards that it itself does not meet. The author makes that point through the above examples and many others. The sheer number of examples suggests that this is a regular pattern in the book. The reason seems simple enough: it's really easy to give general advice about writing software. But it's quite another thing to put that advice into practice as the thing you're working on turns to goo, which is exactly what appears to have happened with Martin's model project, FitNesse.
- initplus 4y ago
  Even outside the context of refactoring/extending an existing codebase the code examples seem bad, look at his example of a prime generator from the bottom of the article. Think it’s more a case of “your own sh*t doesn’t smell”.
ZephyrBlu 4y ago
I like Carmack's approach to functions the best: "If a function is only called from a single place, consider inlining it. If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters. If the work is close to purely functional, with few references to global state, try to make it completely functional. Try to use const on both parameters and functions when the function really must be used in multiple places. Minimize control flow complexity and “area under ifs”, favoring consistent execution paths and times over “optimally” avoiding unnecessary work." http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html http://number-none.com/blow/blog/programming/2014/09/26/carm...
- jacquesm 4y ago
  > If a function is only called from a single place, consider inlining it. A compiler should do this for you. > If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. This makes no sense to me. > If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters. This can be useful, but only if it does not mess up code readability unless you are trying to squeeze your code into a cache. > If the work is close to purely functional, with few references to global state, try to make it completely functional. This makes very good sense, but it can be harder than it seems. One of the easiest ways (depending on how far down the call stack you are) you may just be able to pass the individual parts of that global state in as parameters. > Try to use const on both parameters and functions when the function really must be used in multiple places. Not all languages support this, but where they do this is good practice. In general: limiting scope and mutability is always an advantage. > Minimize control flow complexity and “area under ifs”, favoring consistent execution paths and times over “optimally” avoiding unnecessary work. Is also good advice. In general you want to avoid nesting your ifs too deeply because at some point you lose track of what the local context is that got you there. Then it is usually better to break out a function and name it well so that that context is clear again. In general, naming things well is hard.
dathinab 4y ago
the thing with that book, and many similar books is that if you take the recommendation verbatim they often 1) only apply to one language 2) get outdated really fast. What matters is understanding the "general concept/ideas" and apply them "as appropriate". Most important over obsessing about specific rules is nearly never a good idea, but to some degree that is what is needed to write a book like that to illustrate the idea. And this is also where Clean Code fails, it's often too specific in exactly how to do certain things. But that is also what made it so successful because it makes it accessible. Today Clean Code and some other such books are still a grate source to compare your experience/knowledge against in a critical way to find additional insights. Through if you want a book which you can blindly follow or you don't have the experience to judge code style recommendations its probably best to keep the hands of it.
fzeindl 4y ago
Slightly offtopic but I have summarized my own 20 years of clean coding experience into a system: https://www.fabianzeindl.com/posts/the-codequality-pyramid https://www.fabianzeindl.com/posts/the-codequality-pyramid
- gavinhoward 4y ago
  I like that post of yours. If there's one thing I slightly disagree with, it's that I would put Code Performance below Test Performance, but that's because my personal experience ([1]) has been that code performance affects test performance more than anything else. But still, this is an excellent model, and I'm bookmarking it. Thanks! [1]: https://gavinhoward.com/2019/08/why-perfect-software-is-nearly-impossible/#feedback-must-be-fast https://gavinhoward.com/2019/08/why-perfect-software-is-near...
  - tgv 4y ago
    I think that in terms of "what to strive for", the pyramid makes sense in a generalist way. And, code performance is, as you say, part of test performance. If the tests take too long, perhaps the code needs to be improved. OTOH, I have got a few test suites that run for 30 minutes or more, just because the search space is so big. But that's code that only needs to be tested once.
    - fzeindl 4y ago
      > And, code performance is, as you say, part of test performance. If the tests take too long, perhaps the code needs to be improved. Yes. I mentioned this is in the last section. When test-performance is alright, typically you don't need to optimize code anymore. For me, optimizations in the "code performance" category are for example trading off a generalist API for a more complicated tweaked version that reaches into details and enables caching. The kinds of optimizations game developers do where they make the code less general and pretty, but more performant. > OTOH, I have got a few test suites that run for 30 minutes or more, just because the search space is so big. But that's code that only needs to be tested once. What are these suites testing?
dang 4y ago
Related: It's probably time to stop recommending Clean Code - https://news.ycombinator.com/item?id=29203295 https://news.ycombinator.com/item?id=29203295 - Nov 2021 (88 comments) It's probably time to stop recommending Clean Code (2020) - https://news.ycombinator.com/item?id=27276706 https://news.ycombinator.com/item?id=27276706 - May 2021 (658 comments) It's probably time to stop recommending Clean Code - https://news.ycombinator.com/item?id=23671022 https://news.ycombinator.com/item?id=23671022 - June 2020 (8 comments)
- andirk 4y ago
  It's probably time to stop recommending "It's probably time to stop recommending Clean Code"
  - dang 4y ago
    Reposts are fine on HN after a year or so, if the article is good for HN*. If the article is bad for HN, best not to post it in the first place. I don't know about this article. * https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html
- ravagat 4y ago
  Quite interesting that it's always been the same article
emodendroket 4y ago
This stuff still pops up in the wild so the article is a useful corrective. But one wonders how that sample code ever passed without comment.
DanielVZ 4y ago
Clean Code was one of the first books I read as a History student trying to become a self taught developer. From my point of view, coming from the rigor of historiography, the book was inconsistent and dogmatic. Still I took it as a replacement to talking with an experienced engineer, because that’s how it felt and most of the principles were fine when not taken to the extreme. But now in my career I’ve seen awfully unnecessarily complex code in the name of the SOLID principles and others like DRY. Other times completely misunderstanding what the principles stand for and applying them in hand wavy ways. This is a personal stretch, but even the marketing behind the principles is a bit of a red flag for me (Clean Code, SOLID, UNCLE BOB????). To me it sounds like someone made a career out of this. I wish we had a better book to recommend to newcomers.
- AlexSW 4y ago
  Which SOLID principles have you found issues with, either theoretically or in practice? They still seem like broadly sensible principles to me.
  - DanielVZ 4y ago
    For example the Open Closed principle is often times used to justify a plethora of inheritance chains rather than having a more generic class that can handle cases based on some parameter. Specially when all a subclass does is modify some class attribute or change some implementation by one line. Obviously some times it's good to apply the principle, but not EVERY time it fits.
- MrJohz 4y ago
  I've recommended it before (I think there's even a blog post of mine written in direct response to this article floating around somewhere): A Philosophy of Software Design is really good. It isn't so concerned with all of the details about what exact decisions you should make ("how many lines should my function have?" etc), but rather the high-level design choices that go into those decisions. A lot of the book is spent on the philosophy of interfaces, which is the author's way of describing the boundaries between a piece of code and its caller. It's written by John Ousterhout, of Tcl fame (among many other things) based on his own experience, but also his attempts to teach software engineering to students, and the techniques that worked well for those students in practical situations, so I think it's fairly well grounded in actual advice.
charlie0 4y ago
I personally like this rule of thumb, if a function is hard to test, it's time to simplify some code.
kdazzle 4y ago
I dont know - i think it still holds up. It just takes a little experience to learn to not be so literal with it.
YouWhy 4y ago
Towards the end of my tenure in a team, a new boss instituted mandatory viewing sessions of Martin's training videos; I grew somewhat averse of them. While the heart of Martin's teachings are about expressivity and semantics, the praxis is much more about recipes than about what matters to me as a professional, which is: 1. Well-definedness of the computation being done (in a mathematical sense of the word), 2. Engineering, that is establishing of a connection between human narratives about what the SW should do with the program's structure. Overall, it seemed to me that Martin is first and foremost trying to sell to sell a certain paradigm of competency to corporate cookie-cutter-culture organizations. My issues with this paradigm of competency are that: 1. Doing it properly requires a massive investment, which does not make business sense. 2. As is often the case, this paradigm makes it easy to feign competence without actually being competent, which is damaging to organizational trust.
- inimino 4y ago
  I agree. Martin's approach is amenable to bureaucracies that want to increase (the perception of) organizational control over software projects. It is opposed to the Fred Brooks approach. It favors a lower standard of individual skill and relies on bureaucratic control of the process instead as the guarantor of good outcomes. We shouldn't be surprised that it's popular, or that it's highly associated with Java (and certain other languages today).
albertopv 4y ago
If OP expects a book, every coding book, will give advices to be followed literally, that's a problem. After 14y I know there's no recipe valid for everyone and every scenario and that's what I always says to new junior devs I have to train: it always depends. Are you prototyping? Are you developing critical infrastructure code, or a website? Restricted resources industrial appliance code? I read that book when I was young, I followed some advices, some I didn't, then I made mine ideas. Of course reading others books is also very helpful to contextualise Clean Code. What I really, really recommend is NOT to read The Clean Coder book by same Rob Martin, it's one of the few I have been unable to even finish, it has been unbearable to me.
andirk 4y ago
Haven't read but it's definitely time to start demanding people write clean code. My house often gets messy, and so does my code. And then I clean my house and refactor my code. I try to steer away from refactoring for the sake of making my code look sexy, which it does, but putting time on the calendar for an almost guaranteed need to shuffle things around when you get a chance feels good and makes your future self happier. A lot of people have no idea how to write clean code and those parts of codebases and those people should be avoided as much as possible. I'm not trying to hate, but wow some devs have no shame.
- adlpz 4y ago
  The issue is that the meaning of "clean code" here isn't code that's clean and legible. It's code written in the typically over engineered OOP-heavy Java style. Think lots of "patterns", massive amounts of inheritance, interfaces and factories everywhere. I made the decision of abandoning any clean-code-ish practices within my teams long ago. I still demand the code to be structured sensibly, be clear, well named and documented.
  - andirk 4y ago
    "clean" means more formal and specific?? That's often the opposite of clean. But ok understood. I should have read the article. Let's not add LOC if it's not helpful. I finally picked up Typescript to strengthen my Javascript code, and I'm a huge fan now, but a lot of the added features aren't always helpful whether because of project size or complexity. And the typeahead -> add code features on IDEs add a lot of bloat like yeah interfaces on _everything_.
ornornor 4y ago
From my decade writing software professionally and my current job search, I really question the actual demand for clean code. That’s unfortunate because it’s my specialty and what gives me job satisfaction. I love fixing things. I actually enjoy working on a crappy codebase that has made the company money but is now too hard to maintain/extend and needs cleaning. Adding tests, refactoring, extracting functionality to discrete functions, figuring out what the black box actually does, etc. This is what I’ve specialized in. However, it seems to me that companies don’t actually value that. They all say they do of course, while actually being afraid of doing this because it takes more time and money. Even if they’re mature enough that survival isn’t an immediate concern anymore, there is time to clean things up, and the mess is actually slowing them down through downtime, bugs, and not being able to ship relatively trivial features/updates in less than weeks. I also suspect that not focusing on clean code is a strategy many managers have because they can show velocity to their higher ups and get promoted before it all blows up and they’re held responsible. So what do you all think? Is clean code really actually valuable in the eyes of organizations or will they always take the quicker and dirtier option given the choice? Will I ever find work selling code cleaning (even to companies that ask for it) or should I “rebrand” on fast and cheap code at the expense of quality?
- emodendroket 4y ago
  Of course the people signing the checks don't care about that directly, but it's something you can do as you add functionality.
  - ornornor 4y ago
    That’s my understanding as well, quality for the sake of it isn’t appealing. But it is known that a quality foundation enables everything in the business, reduces waste, churn, and increases profits. Yet when it comes down to actually doing it, nobody cares. Fast and cheap always wins over quality. That’s not necessarily a problem overall, but it is for me because I derive no satisfaction from shipping low quality code and the constant firefighting that results. This is a struggle because it’s the vast majority of the demand for software, which makes me want to quit the industry altogether even though I love programming and improving “legacy” codebase. But there seem to be no actual demand for this skill despite the appearances.
moomoo11 4y ago
Eh. I like that people who actually understand the principles behind Clean Code can share a common understanding of how we are going to put the legos together. Don’t have to spend too much time bikeshedding. Experienced enough to have some foresight and pragmatic enough to know where to draw the line.
dietrichepp 4y ago
My experience is that I run into a lot of relatively junior programmers who are concerned about clean code. Is my code clean? How do I organize my code? How do I make it clean? Should we clean up this code? I almost never want to use the word “clean” when I’m talking about code. These days, when someone asks me to review code, and they start talking about “clean” code, I shift the discussion to two points—code should be correct and easy to understand. I think “correct and easy to understand” is a much more useful rubric than “clean”. Obviously it’s still subjective. Code that is easy to understand for you may be hard for me to understand. Likewise, code that is correct for your use cases may be incorrect for my use cases. But it’s much easier to come to an agreement about “correct and easy to understand”, or at least communicate issues with the code using that basis. Like, “you shouldn’t use boolean flags as parameters, you should use enums” becomes “I can‘t understand the meaning of true/false at the call site, so let’s use an enum instead”. This gives us a very clear, articulable basis for how we talk about code quality. Of course, “correct and easy to understand” is not the be-all and end-all for describing good code. It’s just a nice substitute for the horribly vague, terribly subjective “clean”.
- cush 4y ago
  It can definitely be confusing to hear "clean" when communicating in a professional setting. That said, in the book he covers correctness and understandability in nearly every paragraph. It's all the book is about really. It's called "clean" because it's concise and a catchy book title.
  - dietrichepp 4y ago
    If you say the book “covers correctness and understandability in nearly every paragraph” then I’m convinced we must be talking about different books. For example, the book presents a rule for class names: > Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be a verb. What a proclamation! We could connect this to correctness and understandability. But the book does not. You could say that it is harder to understand a class named “SomethingManager” because “manager” is vague, and more specific words are usually preferred. Instead, the book presents a rule, without explanation or example. Kind of like the Strunk & White book on style, and if you like Strunk & White, then we disagree on at least two books. That’s my general complaint about the book. Too many proclamations, too much doctrine, not enough explanation or foundation.
rhizome31 4y ago
I haven't read Clean Code but one book that helped me get better at coding was Refactoring by Martin Fowler. There's a second edition that uses JavaScript instead of Java. Anyone read it recently?
- balb0a 4y ago
  Yes, good read.
Groxx 4y ago
Yeah. This fits with my reading of it as well. Periodic chunks of "yep, makes sense" scattered through a really disturbing miasma of questionable stuff and incredibly tightly bound methods sharing gigantic balls of state that must be called in an order, but with nothing that hints at or enforces that order. It adds up to a really horrific result pretty frequently. I'm not sure how it got its status at the beginning, but I think it retains it through sheer scale - it's a gigantic book for what it actually contains. It batters you with poorly connected ideas over and over and over until you can't tell right from wrong, and in the end you're just agreeing with whatever because doing otherwise gets you nowhere and nothing but pain as you try to read more. It's like a cult brainwashing ritual.
- emodendroket 4y ago
  It reminds me of the Elements of Style, which has for decades had a reputation as the book every English writer should read. In reality, it's a mix of obvious truisms ("omit needless words," gee, thanks, but how do I identify the needless ones?) and grammatical advice where the authors are so confused about the concepts that they constantly violate their own precepts. However, at least EB White was a talented author whose writing was beloved. Seems hard to say much complimentary about the sample code presented here.
  - deleted 4y ago
    [deleted]
- tgv 4y ago
  I once stated a few of the author's criticisms in a forum, one of which was the 3 line function, only to get a reply from Martin himself, saying that he hadn't written that. Unfortunately for him, everybody reads it in the book, and his apostles repeat it, and it's part of his success.
  - deleted 4y ago
    [deleted]
- gs17 4y ago
matsemann 4y ago
Meh, I don't get the hate for Clean Code, or other books like this. Should you take everything it says as gospel? No. Did reading it in the beginning of my career make me a better developer? Yes. Its the same as with every other practice. Do I practice TDD? No. Did trying it out for some time learn me things I still apply to code I write 10 years later? Yes.
- iainmerrick 4y ago
  Don’t you think the example code quoted looks really bad? If the code is that bad, why should the advice be trusted?
  - leftbit 4y ago
    Don't know if this is really a bad thing - had the same problems with the book, but the apparent contradictions made me really think about the stuff. So I'm quite prepared to consider his advice, I'd never turn it into gospel.
  - mtrower 4y ago
    Is the advice to be trusted though, or merely considered?
al-king 4y ago
I think _entirely_ ignoring the kinds of considerations it covers is such a typical failure case for inexperienced programmers (or non-career coders) that it's an excellent prod to expand the scope of what enters their awareness when writing code. Ideally folks notice discrepancies between their experiences and the things it recommends and find their taste and judgement that way, though it doesn't always work out. So like, maybe the fact that some of the advice is clearly dreadful if you try it could be a useful wedge against the kind of cult thinking so pervasive in software. I've seen considerably more grief from people treating his SOLID stuff like a bible that clean code. YMMV.
revskill 4y ago
Just because developers lack common understanding on what, how to do Clean Coding, made me think NoCode is the future. Developers are just bad as coding. In general, human being lacks ability to clean code.
blt 4y ago
I get the impression that Uncle Bob Martin worked on CRUD-type projects with very few interesting design decisions to be made about what the software should do computationally. In these projects, the programmer's mind wanders. It latches onto the endless design decisions one can dream up about how the source code should be organized. It's hard to imagine anyone going this far down the rabbit hole of strange code organization when they are facing serious challenges like real-time demands, high concurrency, reliability, complex algorithms, big data, embedded systems, etc.
- ornornor 4y ago
  > CRUD-type projects with very few interesting design decisions to be made about what the software should do computationally. Isn’t this by far the bulk of code businesses produce and need though? Very few businesses actually have the scale or product that requires more than a glorified CRUD with arcane business rules slapped on top.
  - eurasiantiger 4y ago
    Actually it can get really complex really fast if the business rules happen to apply to migrations and operations on heavily relational data, especially with composite keys involving date ranges.
    - ornornor 4y ago
      Then the advice in clean code and other similar books apply. Parent comment implied the book isn’t relevant because it only applies to CRUD apps and I argue that they’re the vast majority of code produced so while the book isn’t relevant to 100% of codebases, it is useful advice in the majority of cases nevertheless. Edge cases are gonna be edgecases and will require tailored advice.
admo1 4y ago
Am I the only one who thinks it's a great book and that it should still be among the top books to be recommended ? Maybe not the first one but easily in the top 10. Each time I see the same discussion on HN about this book, I'm always wondering why I see so many people going in either direction : not following the advice of the book at all, or following it too religiously. For me, the philosophy of the books was always about "having a set of guidance on how to improve your code, IF YOU NEED IT", and never about a strict set of rules that were mandatory to follow in order to have "clean code". The fact that the book gives strong statements about what clean code is, such as "a function should be only one line" was always an exaggeration for me, albeit a useful one to actually makes the reader think more deeply about its function length, but never about forcing you to split your 1000 lines functions into 100 functions of 10 lines, if you don't need it.
- leftbit 4y ago
  Exactly that - the subtitle really says it all: "A Handbook of Agile Software Craftsmanship" A craftsman is an expert in his field who applies his knowledge and techniques judiciously, not religiously or automatically.
- ravagat 4y ago
  You're not alone, its a great book and one of the better ones to be recommended but shouldn't be the only one. Unfortunately a lot of folks do exactly that.
codeape 4y ago
Joel Spolsky's (harsh) comments on SOLID, from a 2009 episode of the Stack Overflow podcast (https://stackoverflow.blog/2009/01/22/podcast-38/ https://stackoverflow.blog/2009/01/22/podcast-38/ https://stackoverflow.fogbugz.com/default.asp?pg=pgWiki&command=view&ixWikiPage=29025 https://stackoverflow.fogbugz.com/default.asp?pg=pgWiki&comm...): "And, when I was listening to them, they all sounded to me like, to me, extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code, frankly."
brundolf 4y ago
"So... imagine that someone enters a kitchen, because they want to show you how to make a cup of coffee. As you watch carefully, they flick a switch on the wall. The switch looks like a light switch, but none of the lights in the kitchen turn on or off. Next, they open a cabinet and take down a mug, set it on the worktop, and then tap it twice with a teaspoon. They wait for thirty seconds, and finally they reach behind the refrigerator, where you can't see, and pull out a different mug, this one full of fresh coffee. ...What just happened? What was flicking the switch for? Was tapping the empty mug part of the procedure? Where did the coffee come from? That's what this code is like." This is such a good metaphor
camgunz 4y ago
I definitely agree that Clean Code is past its expiration date. In its place I'd recommend Code Complete, Rapid Development, A Philosophy of Software Design, and The Practice of Programming. I think more than any specific book is that by reading multiple opinionated viewpoints you'll start developing taste of your own that's grounded in a pretty good survey of approaches. If your philosophy is literally based on one book, you should probably read at least one other one.
ravagat 4y ago
The biggest (in terms of impact) detriment I've seen of Clean Code has been a lot of diluted information passed down from and to devs who haven't bothered to read the actual book. A lot of context gets lost in translation and really the the term "Clean Code" became more myth/stereotype like.
guhcampos 4y ago
The only programing principle anyone will ever need is the Principle of Least Surprise. Everything else can and should be constantly re-evaluated.
akullpp 4y ago
I wouldn't recommend it either, it is a very simplistic view of coding with some bad advice intermingled. Obviously reality is much more complex than any book could describe and there is benefit to think about bad examples as well as good ones. Though it is an ill-defined term clean (clear, readable, reasonable, understandable) code is important in the sense that accidental complexity should be minimized and encapsulated and necessary complexity should be understandable.

202 points by flykespice 4y ago

The amount of money I've spared to a companies by first learning the importance of Clean Code before I've tackled projects are immeasurable. Sure, Uncle Bob might be to opinionated and you might not like him, and some coding practices you might not agree with, and are indeed unnecessary today, but rules are important, and this is what we're missing today. Ground set rules, so everyone is on the same page.

phendrenad2 4y ago
What's important is that people have the shared language of Clean Code (or some other repository of best practices, could be integrated into your company styleguide, for instance). I.E. If Uncle Bob said "Don't do X" then we can have a conversation in that context if, in this scenario, doing X is acceptable. Without that logical reasoning, people will debate the very existence of "not doing X" as a best practice.
- DanielVZ 4y ago
  Except having these discussions is really hard. It ends up being you against uncle bob and you are not gonna win that argument against a senior-er engineer.
  - leftbit 4y ago
    Don't think so. If the senior engineer is worth his salt he should know that programming is always about finding a balance between several aspects of a given problem - some of them technical, some of them human. As long as the code does what it's supposed to do the rest is mostly up to personal taste - so yes, you can have an insightful discussion, but there's only to learn, nothing to "win" for all participants.
    - DanielVZ 4y ago
      Yep, but in practice Seniority comes either from experience or time in the industry. So you'll undoubtedly meet seniors that won't try to find that balance.
leftbit 4y ago
> but rules are important, and this is what we're missing today. Programming rules are important - they make you think before you break them. Just don't turn rules into dogma - otherwise your devs will be more concerned with following the rules than solving the actual business problems. And you don't want that.
- DotaFan 4y ago
  You should certainly be flexible around it, visit them every now and then to update. Also, we should enforce them once they are set.
  - leftbit 4y ago
    Really don't like the enforcing. Okay, mixed feelings there. Rules should help you along, perhaps set a framework for your thinking. But they never should limit you in achieving your goal. When establishing a rule you should also specify what you want to achieve by it, how you'll measure its effects and under which conditions it should be removed. Rigid rule enforcement has a strong danger of shifting the priorities of the developers to the detriment of your business.

userbinator 4y ago

A common theme not only in software but other industries: Beware of people selling you advice. They are the ones who will breed dogmatic illogical cargo-cults of people whose only rebuttal when questioned is some variant of "because someone who sold me this book that claims it'll make my code better said so", and that can't be a good thing in general. but we assume that Martin doesn't literally mean that every function in our entire application must be four lines long or less. Unfortunately I have worked (and fortunately, briefly!) with codebases like that --- not surprisingly, in Java. In addition to the complexity of whatever the code is doing, smashing things into tiny pieces also adds its own complexity. The fact that a short function is "easily understandable" on its own, which is what a lot of proponents of this dogma argue, is useless for understanding the functioning of the whole. The latter is far more important when debugging. Function length is ultimately meaningless. I'd rather have a 5000-line function that reads top-to-bottom, than 1000 5-line functions if it means I don't have to jump around several-dozen-level-deep callstacks and try to keep track of 30+ character long identifiers to understand how the thing works.

rightbyte 4y ago
Ye flat functions are way underrated. It is so hard to keep track of the call stack when reading code for me. Deeply nested code is read only, unless the problem is nicely modelled as recursive in some way.
- eurasiantiger 4y ago
  And what kind of problem is nicely modelled as recursive? It’s when your data items have children, which can have children, which can have children...
tmaly 4y ago
I had a similar experience. There was a developer in my group that adhered to Clean Code. Four line functions made everything verbose. When he left I had to take over all of his code. The one part of Clean Code that saved my sanity was his choice of names and flow. That made it somewhat easier to navigate. I have experiences with other code where it was so abstract, it took much longer to figure out. I like to go by the rule: "write code for the average developer". I think finding that balance makes it easier to grok the code and maintain it.

bitwize 4y ago

[flagged]

avg_dev 4y ago

Wow this is quite a takedown. For many years I was feeling like I let myself down by not reading the book Clean Code. I now feel like, by accident, I did exactly the right thing. That sample code he quoted is near unreadable to me. I also did enjoy A Philosophy of Software Design; the main thing I took away from it was to avoid unneeded complexity because you want to be able to “spend” your complexity budget for doing actual work.

DotaFan 4y ago
Blog is addressing small segment of a book, you might still be missing a good learning. Maybe you can scrim some chapters here: https://dev.to/thawkin3/in-defense-of-clean-code-100-pieces-of-timeless-advice-from-uncle-bob-5flk https://dev.to/thawkin3/in-defense-of-clean-code-100-pieces-...
rgoulter 4y ago
I generally liked APoSD. I liked its notion of symptoms of complex code. I liked its framing of complexity as related to dependencies involved in calling some function. -- If a function has more parameters than it really needs (too many dependencies), or a function has fewer parameters than it actually needs, then it's more complicated to work with than it needs to be (its actual dependencies are obscure). -- I liked its emphasis on "interface" is "what you need to know to use the code", as opposed to implementation details. I liked the suggestion of "writing documentation before the implementation" as a way of coming up with a clean interface; although I found it bizarre that this logic didn't carry across to "write some tests before the implementation".
crucialfelix 4y ago
If you read the book, understand the principals and then disagree with a few of them, you will have learned more than if you never read it at all.

Octokiddie 4y ago

> Martin states, in this very chapter, that it makes sense to break a function down into smaller functions "if you can extract another function from it with a name that is not merely a restatement of its implementation". But then he gives us: [function that restates its implementation] and [function that restates its implementation] The article's main beef is that Clean Code sets standards that it itself does not meet. The author makes that point through the above examples and many others. The sheer number of examples suggests that this is a regular pattern in the book. The reason seems simple enough: it's really easy to give general advice about writing software. But it's quite another thing to put that advice into practice as the thing you're working on turns to goo, which is exactly what appears to have happened with Martin's model project, FitNesse.

initplus 4y ago
Even outside the context of refactoring/extending an existing codebase the code examples seem bad, look at his example of a prime generator from the bottom of the article. Think it’s more a case of “your own sh*t doesn’t smell”.

ZephyrBlu 4y ago

I like Carmack's approach to functions the best: "If a function is only called from a single place, consider inlining it. If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters. If the work is close to purely functional, with few references to global state, try to make it completely functional. Try to use const on both parameters and functions when the function really must be used in multiple places. Minimize control flow complexity and “area under ifs”, favoring consistent execution paths and times over “optimally” avoiding unnecessary work." http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html http://number-none.com/blow/blog/programming/2014/09/26/carm...

jacquesm 4y ago
> If a function is only called from a single place, consider inlining it. A compiler should do this for you. > If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. This makes no sense to me. > If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters. This can be useful, but only if it does not mess up code readability unless you are trying to squeeze your code into a cache. > If the work is close to purely functional, with few references to global state, try to make it completely functional. This makes very good sense, but it can be harder than it seems. One of the easiest ways (depending on how far down the call stack you are) you may just be able to pass the individual parts of that global state in as parameters. > Try to use const on both parameters and functions when the function really must be used in multiple places. Not all languages support this, but where they do this is good practice. In general: limiting scope and mutability is always an advantage. > Minimize control flow complexity and “area under ifs”, favoring consistent execution paths and times over “optimally” avoiding unnecessary work. Is also good advice. In general you want to avoid nesting your ifs too deeply because at some point you lose track of what the local context is that got you there. Then it is usually better to break out a function and name it well so that that context is clear again. In general, naming things well is hard.

dathinab 4y ago

the thing with that book, and many similar books is that if you take the recommendation verbatim they often 1) only apply to one language 2) get outdated really fast. What matters is understanding the "general concept/ideas" and apply them "as appropriate". Most important over obsessing about specific rules is nearly never a good idea, but to some degree that is what is needed to write a book like that to illustrate the idea. And this is also where Clean Code fails, it's often too specific in exactly how to do certain things. But that is also what made it so successful because it makes it accessible. Today Clean Code and some other such books are still a grate source to compare your experience/knowledge against in a critical way to find additional insights. Through if you want a book which you can blindly follow or you don't have the experience to judge code style recommendations its probably best to keep the hands of it.

fzeindl 4y ago

Slightly offtopic but I have summarized my own 20 years of clean coding experience into a system: https://www.fabianzeindl.com/posts/the-codequality-pyramid https://www.fabianzeindl.com/posts/the-codequality-pyramid

gavinhoward 4y ago
I like that post of yours. If there's one thing I slightly disagree with, it's that I would put Code Performance below Test Performance, but that's because my personal experience ([1]) has been that code performance affects test performance more than anything else. But still, this is an excellent model, and I'm bookmarking it. Thanks! [1]: https://gavinhoward.com/2019/08/why-perfect-software-is-nearly-impossible/#feedback-must-be-fast https://gavinhoward.com/2019/08/why-perfect-software-is-near...
- tgv 4y ago
  I think that in terms of "what to strive for", the pyramid makes sense in a generalist way. And, code performance is, as you say, part of test performance. If the tests take too long, perhaps the code needs to be improved. OTOH, I have got a few test suites that run for 30 minutes or more, just because the search space is so big. But that's code that only needs to be tested once.
  - fzeindl 4y ago
    > And, code performance is, as you say, part of test performance. If the tests take too long, perhaps the code needs to be improved. Yes. I mentioned this is in the last section. When test-performance is alright, typically you don't need to optimize code anymore. For me, optimizations in the "code performance" category are for example trading off a generalist API for a more complicated tweaked version that reaches into details and enables caching. The kinds of optimizations game developers do where they make the code less general and pretty, but more performant. > OTOH, I have got a few test suites that run for 30 minutes or more, just because the search space is so big. But that's code that only needs to be tested once. What are these suites testing?

dang 4y ago

Related: It's probably time to stop recommending Clean Code - https://news.ycombinator.com/item?id=29203295 https://news.ycombinator.com/item?id=29203295 - Nov 2021 (88 comments) It's probably time to stop recommending Clean Code (2020) - https://news.ycombinator.com/item?id=27276706 https://news.ycombinator.com/item?id=27276706 - May 2021 (658 comments) It's probably time to stop recommending Clean Code - https://news.ycombinator.com/item?id=23671022 https://news.ycombinator.com/item?id=23671022 - June 2020 (8 comments)

andirk 4y ago
It's probably time to stop recommending "It's probably time to stop recommending Clean Code"
- dang 4y ago
  Reposts are fine on HN after a year or so, if the article is good for HN*. If the article is bad for HN, best not to post it in the first place. I don't know about this article. * https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html
ravagat 4y ago
Quite interesting that it's always been the same article

emodendroket 4y ago

This stuff still pops up in the wild so the article is a useful corrective. But one wonders how that sample code ever passed without comment.

DanielVZ 4y ago

Clean Code was one of the first books I read as a History student trying to become a self taught developer. From my point of view, coming from the rigor of historiography, the book was inconsistent and dogmatic. Still I took it as a replacement to talking with an experienced engineer, because that’s how it felt and most of the principles were fine when not taken to the extreme. But now in my career I’ve seen awfully unnecessarily complex code in the name of the SOLID principles and others like DRY. Other times completely misunderstanding what the principles stand for and applying them in hand wavy ways. This is a personal stretch, but even the marketing behind the principles is a bit of a red flag for me (Clean Code, SOLID, UNCLE BOB????). To me it sounds like someone made a career out of this. I wish we had a better book to recommend to newcomers.

AlexSW 4y ago
Which SOLID principles have you found issues with, either theoretically or in practice? They still seem like broadly sensible principles to me.
- DanielVZ 4y ago
  For example the Open Closed principle is often times used to justify a plethora of inheritance chains rather than having a more generic class that can handle cases based on some parameter. Specially when all a subclass does is modify some class attribute or change some implementation by one line. Obviously some times it's good to apply the principle, but not EVERY time it fits.
MrJohz 4y ago
I've recommended it before (I think there's even a blog post of mine written in direct response to this article floating around somewhere): A Philosophy of Software Design is really good. It isn't so concerned with all of the details about what exact decisions you should make ("how many lines should my function have?" etc), but rather the high-level design choices that go into those decisions. A lot of the book is spent on the philosophy of interfaces, which is the author's way of describing the boundaries between a piece of code and its caller. It's written by John Ousterhout, of Tcl fame (among many other things) based on his own experience, but also his attempts to teach software engineering to students, and the techniques that worked well for those students in practical situations, so I think it's fairly well grounded in actual advice.

charlie0 4y ago

I personally like this rule of thumb, if a function is hard to test, it's time to simplify some code.

kdazzle 4y ago

I dont know - i think it still holds up. It just takes a little experience to learn to not be so literal with it.

YouWhy 4y ago

Towards the end of my tenure in a team, a new boss instituted mandatory viewing sessions of Martin's training videos; I grew somewhat averse of them. While the heart of Martin's teachings are about expressivity and semantics, the praxis is much more about recipes than about what matters to me as a professional, which is: 1. Well-definedness of the computation being done (in a mathematical sense of the word), 2. Engineering, that is establishing of a connection between human narratives about what the SW should do with the program's structure. Overall, it seemed to me that Martin is first and foremost trying to sell to sell a certain paradigm of competency to corporate cookie-cutter-culture organizations. My issues with this paradigm of competency are that: 1. Doing it properly requires a massive investment, which does not make business sense. 2. As is often the case, this paradigm makes it easy to feign competence without actually being competent, which is damaging to organizational trust.

inimino 4y ago
I agree. Martin's approach is amenable to bureaucracies that want to increase (the perception of) organizational control over software projects. It is opposed to the Fred Brooks approach. It favors a lower standard of individual skill and relies on bureaucratic control of the process instead as the guarantor of good outcomes. We shouldn't be surprised that it's popular, or that it's highly associated with Java (and certain other languages today).

albertopv 4y ago

If OP expects a book, every coding book, will give advices to be followed literally, that's a problem. After 14y I know there's no recipe valid for everyone and every scenario and that's what I always says to new junior devs I have to train: it always depends. Are you prototyping? Are you developing critical infrastructure code, or a website? Restricted resources industrial appliance code? I read that book when I was young, I followed some advices, some I didn't, then I made mine ideas. Of course reading others books is also very helpful to contextualise Clean Code. What I really, really recommend is NOT to read The Clean Coder book by same Rob Martin, it's one of the few I have been unable to even finish, it has been unbearable to me.

andirk 4y ago

Haven't read but it's definitely time to start demanding people write clean code. My house often gets messy, and so does my code. And then I clean my house and refactor my code. I try to steer away from refactoring for the sake of making my code look sexy, which it does, but putting time on the calendar for an almost guaranteed need to shuffle things around when you get a chance feels good and makes your future self happier. A lot of people have no idea how to write clean code and those parts of codebases and those people should be avoided as much as possible. I'm not trying to hate, but wow some devs have no shame.

adlpz 4y ago
The issue is that the meaning of "clean code" here isn't code that's clean and legible. It's code written in the typically over engineered OOP-heavy Java style. Think lots of "patterns", massive amounts of inheritance, interfaces and factories everywhere. I made the decision of abandoning any clean-code-ish practices within my teams long ago. I still demand the code to be structured sensibly, be clear, well named and documented.
- andirk 4y ago
  "clean" means more formal and specific?? That's often the opposite of clean. But ok understood. I should have read the article. Let's not add LOC if it's not helpful. I finally picked up Typescript to strengthen my Javascript code, and I'm a huge fan now, but a lot of the added features aren't always helpful whether because of project size or complexity. And the typeahead -> add code features on IDEs add a lot of bloat like yeah interfaces on _everything_.

ornornor 4y ago

From my decade writing software professionally and my current job search, I really question the actual demand for clean code. That’s unfortunate because it’s my specialty and what gives me job satisfaction. I love fixing things. I actually enjoy working on a crappy codebase that has made the company money but is now too hard to maintain/extend and needs cleaning. Adding tests, refactoring, extracting functionality to discrete functions, figuring out what the black box actually does, etc. This is what I’ve specialized in. However, it seems to me that companies don’t actually value that. They all say they do of course, while actually being afraid of doing this because it takes more time and money. Even if they’re mature enough that survival isn’t an immediate concern anymore, there is time to clean things up, and the mess is actually slowing them down through downtime, bugs, and not being able to ship relatively trivial features/updates in less than weeks. I also suspect that not focusing on clean code is a strategy many managers have because they can show velocity to their higher ups and get promoted before it all blows up and they’re held responsible. So what do you all think? Is clean code really actually valuable in the eyes of organizations or will they always take the quicker and dirtier option given the choice? Will I ever find work selling code cleaning (even to companies that ask for it) or should I “rebrand” on fast and cheap code at the expense of quality?

emodendroket 4y ago
Of course the people signing the checks don't care about that directly, but it's something you can do as you add functionality.
- ornornor 4y ago
  That’s my understanding as well, quality for the sake of it isn’t appealing. But it is known that a quality foundation enables everything in the business, reduces waste, churn, and increases profits. Yet when it comes down to actually doing it, nobody cares. Fast and cheap always wins over quality. That’s not necessarily a problem overall, but it is for me because I derive no satisfaction from shipping low quality code and the constant firefighting that results. This is a struggle because it’s the vast majority of the demand for software, which makes me want to quit the industry altogether even though I love programming and improving “legacy” codebase. But there seem to be no actual demand for this skill despite the appearances.

moomoo11 4y ago

Eh. I like that people who actually understand the principles behind Clean Code can share a common understanding of how we are going to put the legos together. Don’t have to spend too much time bikeshedding. Experienced enough to have some foresight and pragmatic enough to know where to draw the line.

dietrichepp 4y ago

My experience is that I run into a lot of relatively junior programmers who are concerned about clean code. Is my code clean? How do I organize my code? How do I make it clean? Should we clean up this code? I almost never want to use the word “clean” when I’m talking about code. These days, when someone asks me to review code, and they start talking about “clean” code, I shift the discussion to two points—code should be correct and easy to understand. I think “correct and easy to understand” is a much more useful rubric than “clean”. Obviously it’s still subjective. Code that is easy to understand for you may be hard for me to understand. Likewise, code that is correct for your use cases may be incorrect for my use cases. But it’s much easier to come to an agreement about “correct and easy to understand”, or at least communicate issues with the code using that basis. Like, “you shouldn’t use boolean flags as parameters, you should use enums” becomes “I can‘t understand the meaning of true/false at the call site, so let’s use an enum instead”. This gives us a very clear, articulable basis for how we talk about code quality. Of course, “correct and easy to understand” is not the be-all and end-all for describing good code. It’s just a nice substitute for the horribly vague, terribly subjective “clean”.

cush 4y ago
It can definitely be confusing to hear "clean" when communicating in a professional setting. That said, in the book he covers correctness and understandability in nearly every paragraph. It's all the book is about really. It's called "clean" because it's concise and a catchy book title.
- dietrichepp 4y ago
  If you say the book “covers correctness and understandability in nearly every paragraph” then I’m convinced we must be talking about different books. For example, the book presents a rule for class names: > Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be a verb. What a proclamation! We could connect this to correctness and understandability. But the book does not. You could say that it is harder to understand a class named “SomethingManager” because “manager” is vague, and more specific words are usually preferred. Instead, the book presents a rule, without explanation or example. Kind of like the Strunk & White book on style, and if you like Strunk & White, then we disagree on at least two books. That’s my general complaint about the book. Too many proclamations, too much doctrine, not enough explanation or foundation.

rhizome31 4y ago

I haven't read Clean Code but one book that helped me get better at coding was Refactoring by Martin Fowler. There's a second edition that uses JavaScript instead of Java. Anyone read it recently?

balb0a 4y ago
Yes, good read.

Groxx 4y ago

Yeah. This fits with my reading of it as well. Periodic chunks of "yep, makes sense" scattered through a really disturbing miasma of questionable stuff and incredibly tightly bound methods sharing gigantic balls of state that must be called in an order, but with nothing that hints at or enforces that order. It adds up to a really horrific result pretty frequently. I'm not sure how it got its status at the beginning, but I think it retains it through sheer scale - it's a gigantic book for what it actually contains. It batters you with poorly connected ideas over and over and over until you can't tell right from wrong, and in the end you're just agreeing with whatever because doing otherwise gets you nowhere and nothing but pain as you try to read more. It's like a cult brainwashing ritual.

emodendroket 4y ago
It reminds me of the Elements of Style, which has for decades had a reputation as the book every English writer should read. In reality, it's a mix of obvious truisms ("omit needless words," gee, thanks, but how do I identify the needless ones?) and grammatical advice where the authors are so confused about the concepts that they constantly violate their own precepts. However, at least EB White was a talented author whose writing was beloved. Seems hard to say much complimentary about the sample code presented here.
- deleted 4y ago
  [deleted]
tgv 4y ago
I once stated a few of the author's criticisms in a forum, one of which was the 3 line function, only to get a reply from Martin himself, saying that he hadn't written that. Unfortunately for him, everybody reads it in the book, and his apostles repeat it, and it's part of his success.
- deleted 4y ago
  [deleted]
gs17 4y ago

matsemann 4y ago

Meh, I don't get the hate for Clean Code, or other books like this. Should you take everything it says as gospel? No. Did reading it in the beginning of my career make me a better developer? Yes. Its the same as with every other practice. Do I practice TDD? No. Did trying it out for some time learn me things I still apply to code I write 10 years later? Yes.

iainmerrick 4y ago
Don’t you think the example code quoted looks really bad? If the code is that bad, why should the advice be trusted?
- leftbit 4y ago
  Don't know if this is really a bad thing - had the same problems with the book, but the apparent contradictions made me really think about the stuff. So I'm quite prepared to consider his advice, I'd never turn it into gospel.
- mtrower 4y ago
  Is the advice to be trusted though, or merely considered?

al-king 4y ago

I think _entirely_ ignoring the kinds of considerations it covers is such a typical failure case for inexperienced programmers (or non-career coders) that it's an excellent prod to expand the scope of what enters their awareness when writing code. Ideally folks notice discrepancies between their experiences and the things it recommends and find their taste and judgement that way, though it doesn't always work out. So like, maybe the fact that some of the advice is clearly dreadful if you try it could be a useful wedge against the kind of cult thinking so pervasive in software. I've seen considerably more grief from people treating his SOLID stuff like a bible that clean code. YMMV.

revskill 4y ago

Just because developers lack common understanding on what, how to do Clean Coding, made me think NoCode is the future. Developers are just bad as coding. In general, human being lacks ability to clean code.

blt 4y ago

I get the impression that Uncle Bob Martin worked on CRUD-type projects with very few interesting design decisions to be made about what the software should do computationally. In these projects, the programmer's mind wanders. It latches onto the endless design decisions one can dream up about how the source code should be organized. It's hard to imagine anyone going this far down the rabbit hole of strange code organization when they are facing serious challenges like real-time demands, high concurrency, reliability, complex algorithms, big data, embedded systems, etc.

ornornor 4y ago
> CRUD-type projects with very few interesting design decisions to be made about what the software should do computationally. Isn’t this by far the bulk of code businesses produce and need though? Very few businesses actually have the scale or product that requires more than a glorified CRUD with arcane business rules slapped on top.
- eurasiantiger 4y ago
  Actually it can get really complex really fast if the business rules happen to apply to migrations and operations on heavily relational data, especially with composite keys involving date ranges.
  - ornornor 4y ago
    Then the advice in clean code and other similar books apply. Parent comment implied the book isn’t relevant because it only applies to CRUD apps and I argue that they’re the vast majority of code produced so while the book isn’t relevant to 100% of codebases, it is useful advice in the majority of cases nevertheless. Edge cases are gonna be edgecases and will require tailored advice.

admo1 4y ago

Am I the only one who thinks it's a great book and that it should still be among the top books to be recommended ? Maybe not the first one but easily in the top 10. Each time I see the same discussion on HN about this book, I'm always wondering why I see so many people going in either direction : not following the advice of the book at all, or following it too religiously. For me, the philosophy of the books was always about "having a set of guidance on how to improve your code, IF YOU NEED IT", and never about a strict set of rules that were mandatory to follow in order to have "clean code". The fact that the book gives strong statements about what clean code is, such as "a function should be only one line" was always an exaggeration for me, albeit a useful one to actually makes the reader think more deeply about its function length, but never about forcing you to split your 1000 lines functions into 100 functions of 10 lines, if you don't need it.

leftbit 4y ago
Exactly that - the subtitle really says it all: "A Handbook of Agile Software Craftsmanship" A craftsman is an expert in his field who applies his knowledge and techniques judiciously, not religiously or automatically.
ravagat 4y ago
You're not alone, its a great book and one of the better ones to be recommended but shouldn't be the only one. Unfortunately a lot of folks do exactly that.

codeape 4y ago

Joel Spolsky's (harsh) comments on SOLID, from a 2009 episode of the Stack Overflow podcast (https://stackoverflow.blog/2009/01/22/podcast-38/ https://stackoverflow.blog/2009/01/22/podcast-38/ https://stackoverflow.fogbugz.com/default.asp?pg=pgWiki&command=view&ixWikiPage=29025 https://stackoverflow.fogbugz.com/default.asp?pg=pgWiki&comm...): "And, when I was listening to them, they all sounded to me like, to me, extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code, frankly."

brundolf 4y ago

"So... imagine that someone enters a kitchen, because they want to show you how to make a cup of coffee. As you watch carefully, they flick a switch on the wall. The switch looks like a light switch, but none of the lights in the kitchen turn on or off. Next, they open a cabinet and take down a mug, set it on the worktop, and then tap it twice with a teaspoon. They wait for thirty seconds, and finally they reach behind the refrigerator, where you can't see, and pull out a different mug, this one full of fresh coffee. ...What just happened? What was flicking the switch for? Was tapping the empty mug part of the procedure? Where did the coffee come from? That's what this code is like." This is such a good metaphor

camgunz 4y ago

I definitely agree that Clean Code is past its expiration date. In its place I'd recommend Code Complete, Rapid Development, A Philosophy of Software Design, and The Practice of Programming. I think more than any specific book is that by reading multiple opinionated viewpoints you'll start developing taste of your own that's grounded in a pretty good survey of approaches. If your philosophy is literally based on one book, you should probably read at least one other one.

ravagat 4y ago

The biggest (in terms of impact) detriment I've seen of Clean Code has been a lot of diluted information passed down from and to devs who haven't bothered to read the actual book. A lot of context gets lost in translation and really the the term "Clean Code" became more myth/stereotype like.

guhcampos 4y ago

The only programing principle anyone will ever need is the Principle of Least Surprise. Everything else can and should be constantly re-evaluated.

akullpp 4y ago

I wouldn't recommend it either, it is a very simplistic view of coding with some bad advice intermingled. Obviously reality is much more complex than any book could describe and there is benefit to think about bad examples as well as good ones. Though it is an ill-defined term clean (clear, readable, reasonable, understandable) code is important in the sense that accidental complexity should be minimized and encapsulated and necessary complexity should be understandable.