TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Clean Code vs. A Philosophy Of Software Design

488 点作者 recursivedoubts3 个月前

65 条评论

ilitirit3 个月前
It still blows my mind how dogmatic some people can be about things like this. I don&#x27;t understand why anyone takes these things as gospel.<p>Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin?<p>And it&#x27;s not just programming styles, patterns and idioms. It&#x27;s arguably even worse when it comes to tech stacks and solution architecture.<p>It&#x27;s super-frustrating when I&#x27;m dealing with people in a professional setting and they&#x27;re quick to point out something they read in a book, or even worse - a blog - with very little else to add.<p>This was especially bad during the NoSQL and Microservice hype. Still somewhat feeling it with PAAS&#x2F;SAAS and containerization. We have so many really really basic things running as Function Apps or lambdas, or simple transformations running in ADF or Talend that add zero value and only add to the support and maintenance overhead.<p>Always keep in mind that sometimes the only difference between yourself and the person writing the book&#x2F;blog&#x2F;article is that they actually wrote it. And that their opinions were written down don&#x27;t make them fact. Apply your own mind and experience.
评论 #43174260 未加载
评论 #43170891 未加载
评论 #43172400 未加载
评论 #43173581 未加载
评论 #43171374 未加载
评论 #43170361 未加载
评论 #43173326 未加载
评论 #43171232 未加载
评论 #43175860 未加载
评论 #43174292 未加载
评论 #43172549 未加载
评论 #43175712 未加载
评论 #43170285 未加载
评论 #43173842 未加载
评论 #43175326 未加载
评论 #43179833 未加载
评论 #43171155 未加载
评论 #43175011 未加载
评论 #43170460 未加载
评论 #43173886 未加载
评论 #43171672 未加载
评论 #43174063 未加载
Copenjin3 个月前
You just need to work on one project built by someone that implemented Uncle Bob recommendations blindly when the books came out to know how much they are worth. There were some low hanging fruits to pick at the time regarding trying to be better at software engineering and he generated some text about them.<p>Full of terrible advices, he never wrote anything significant (in scope and notoriety) during his time as a software engineer like many other prominent authors at the beginning of the agile era. The success is only the result of a wave of junior devs searching for some sort of guidance, something that there is a never-ending need for.<p>Horrible recommendations that produced a lot of code that is a pain to work on with the abundant amount of indirection it has. Really painful guys.
评论 #43170088 未加载
评论 #43170098 未加载
评论 #43173650 未加载
评论 #43169735 未加载
评论 #43171494 未加载
sudobash13 个月前
There is an important case for comments that neither of them touched on. Sometimes you are dealing with bugs or counterintuitive processes beyond your control.<p>For example, I am writing some driver software for a USB device right now. It is so easy to get the device into a bad state, even when staying within the documented protocol. Every time I implement a workaround, or figure out exactly how the device expects a message to appear, I put in a comment to document it. Otherwise, when (inevitably) the code needs to have features added, or refactoring, I will completely forget why I wrote it that way.<p>The prime number example is a self-contained, deterministic algorithm. While I did find it far easier to parse with comments, I could still spend the time to understand it without them. In my USB device driver, no amount of review without comments would tell another person why I wrote the sequence of commands a certain way, or what timings are important.<p>The only way around that would be with stupid method names like `requestSerialNumberButDontCallThisAfterSettingDisplayData` or `sendDisplayDataButDontCallTwiceWithin100Ms`.
评论 #43167192 未加载
评论 #43168113 未加载
评论 #43169522 未加载
评论 #43167105 未加载
评论 #43168242 未加载
评论 #43171882 未加载
评论 #43169401 未加载
评论 #43172008 未加载
评论 #43170553 未加载
marcusbuffett3 个月前
I strongly recommend &quot;A Philosophy of Software Design&quot;. It basically boils down to measuring the quality of an abstraction by the ratio of the complexity it contains vs the complexity of the interface. Or at least, that&#x27;s the rule of thumb I came away with, and it&#x27;s incredible how far that heuristic takes you. I&#x27;m constantly thinking about my software design in these terms now, and it&#x27;s hugely helpful.<p>I didn&#x27;t feel like my code became better or easier to maintain, after reading other programming advice books, including &quot;Clean Code&quot;.<p>A distant second recommendation is Programming Pearls, which had some gems in it.
评论 #43167731 未加载
jacobsenscott3 个月前
I was around before the clean code movement, and like all software movements, it was a reaction to real problems in the software industry. Massive procedural functions with deeply nested conditionals, no structure, global variables, no testing at all. That was all the norm.<p>Clean Code pushed things in a better direction, but it over-corrected. In many ways APOSD (published in 2018) is a correction against the excesses of Clean Code (published in 2008).<p>Will people swing too far back, to giant methods, deeply nested conditionals, etc? I don&#x27;t know. But probably.
评论 #43170658 未加载
评论 #43169934 未加载
评论 #43170037 未加载
评论 #43170436 未加载
评论 #43179738 未加载
donatj3 个月前
I have worked with a couple of people over the years who instead of breaking functions out when something would say make sense to be reused or made some sort of logical sense as a unit, instead seemingly just bundle lines whose only real relationship was that they happened to be near each other when they decided to &quot;refactor&quot;.<p>Having read Clean Code back in college as it was assigned reading, it was absolutely the vibe I got from Uncle Bob generally. See any number of lines at the same indentation level, select them, extract method, name it vaguely for some part of what it does, repeat.<p>I honestly think that it comes from this type of school of thought that a function should be X lines rather than a function achieving a <i>function</i>. Thinking about this now, it&#x27;s sort of the difference between &quot;subroutines&quot; and &quot;functions&quot;.<p>Working on their code, I thank god for modern IDEs ability to inline. I often go through and restructure the code just to understand the full scope of what it&#x27;s doing, before restoring what I can of the original to make my changes as minimal as possible.
评论 #43171124 未加载
评论 #43174513 未加载
ctrlp3 个月前
I&#x27;ve enjoyed both books but Uncle Bob is something you grow out of. He was a bit of a cult figure at the time. Trying to actually follow the guidelines in Clean Code taught me a lot about &quot;over-decomposition&quot; and, ultimately, how <i>not</i> to write code. It reminds me it&#x27;s possible to take aesthetics so far the results become ugly. Fussing over a proliferation of small functions that do only one thing is a kind of madness. Each individual function eventually does zero things. You are left sifting through the ashes of your program wondering &quot;Where did I go wrong?&quot;<p>On the meta level, these exchanges, while mildly interesting, have the vibe of debating how many angels can dance on the head of a pin. I&#x27;m reminded of the old saying: &quot;Writing about music is like dancing about architecture.&quot; If you want to write good code, read good code. Develop a taste that makes sense to you. I don&#x27;t think I&#x27;ll ever read a book about code composition again.
评论 #43167673 未加载
评论 #43171217 未加载
评论 #43169484 未加载
评论 #43174582 未加载
overgard3 个月前
Bob&#x27;s comments on... commenting.. are so bizarre that I can&#x27;t help but think that he just refuses to concede the point rather than admit he might have been wrong about it. Like, the paranoia around incorrect&#x2F;stale comments is fairly absurd, I&#x27;ve been coding for 20 years across many code bases, and I can&#x27;t even recall a time when I&#x27;ve been significantly mislead by a comment which caused a significant waste of time. However, the amount of time I&#x27;ve wasted on unclear code that has zero comments is absolutely staggering. However, what really sealed the weirdness to me was his argument that this was somehow a good comment:<p><pre><code> X 1111111111111111111111111 1111122222333334444455555666667777788888999990000011111222223333344444 35791357913579135791357913579135791357913579135791357913579135791357913579 !!! !! !! ! !! ! !! ! ! !! ! !! ! ! ! ! !! !! ! 3 |||-||-||-||-||-||-||-||-||-||-||-||-||-||-||-||-||-||-||-||-||- 5 |||||||||||-||||-||||-||||-||||-||||-||||-||||-||||-||||-||||- 7 |||||||||||||||||||||||-||||||-||||||-||||||-||||||-||||||-||||||- 11 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||-||||||||||- 13 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| ... 113|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| </code></pre> That&#x27;s verbatim, I&#x27;m not unfairly clipping context away from it. Like, what the hell is that supposed to tell someone?! Wouldn&#x27;t it just be easier to drop a link to the algorithm, or briefly explain the algorithm, or just give a name of the algorithm so someone can look it up? Instead he just talks about taking a bike ride to understand it and making a weird picture. He also has bizarre arguments that if something can&#x27;t be expressed in a programming language, it&#x27;s the fault of the programming language (what?!) and that code is more understandable than English. I really find it hard to believe that he thinks these are actually good arguments, I just get the impression he does not want to concede that he was wrong about this.
评论 #43171848 未加载
评论 #43168988 未加载
评论 #43168565 未加载
评论 #43174469 未加载
评论 #43242562 未加载
评论 #43170162 未加载
imjonse3 个月前
I am biased ( a former coworker was an Uncle Bob fan, and was bent on doing everything by the book, with layers of abstraction, patterns, hexagonal architecture, lots of unit tests, no cutting corners, even as we did not know what exactly we want to build and needed an MVP ASAP) but I&#x27;ll just say this: Ousterhout wrote TCL - widely considered one of the best C codebases - besides being a professor at Standford and having other software achievements under their belt, while Robert Martin is more like a software technology evangelist. The former good at actual deliverables the latter good at selling.<p>Also Ousterhout&#x27;s book on design is very easy to read and I guess I liked it because I mostly just nodded in approval while reading and there were very few things that made me stop.
评论 #43169669 未加载
评论 #43169088 未加载
seanwilson3 个月前
I find the lack of discussion of type systems really surprising in these sorts of discussions and books. Effective use of type systems is a killer factor for me for creating clean, safe, readable and maintainable software designs.<p>When used correctly, strong static type checking make certain kinds of bugs impossible, spare you from writing many kinds of tedious tests that often get in the way of refactoring, serve as documentation, and make refactoring&#x2F;maintenance an order of magnitude faster and safer. Even when a type checker isn&#x27;t available, avoiding dynamic behaviour is very often the safer way to go so learning how to think in that way is still beneficial.<p>Most of these minor topics like how big a function should be, what to name your variables, or even if you write tests before&#x2F;after coding... it&#x27;s like trying to come up with general rules on how to write essays, creating graphic designs, or how to cook. &quot;It depends&quot; on the context and juggling different priorities each time. It&#x27;s the kind of thing you only learn properly through practice (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Tacit_knowledge" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Tacit_knowledge</a>), so there&#x27;s only so much to gain in reading about it or discussing it after you&#x27;ve defined the no-brainer things to always do and always avoid.
评论 #43171712 未加载
评论 #43168323 未加载
评论 #43172421 未加载
getnormality3 个月前
Uncle Bob&#x27;s insistence that functions should be 2-4 lines long is baffling to me. I don&#x27;t understand how he can be taken seriously. Is there a single application in the entire world with substantial functionality that conforms to this rule?
评论 #43167266 未加载
评论 #43172640 未加载
评论 #43167650 未加载
评论 #43172153 未加载
评论 #43167160 未加载
评论 #43169714 未加载
评论 #43168249 未加载
评论 #43174535 未加载
评论 #43242573 未加载
评论 #43174961 未加载
评论 #43167826 未加载
nickm123 个月前
This was a fun read. I read APoSD for the first time a couple of months ago and found myself nodding enthusiastically as I read. I have a few quibbles, of course, but overall it matches my experience in how to write software that is correct, maintainable, extensible, and understandable.<p>I&#x27;ve never read CC, but I&#x27;ve read some of the take downs[1]. I was worried that the take downs were attacking a strawman, but no, Uncle Bob believes this stuff, including that comments are evil and you just need to read all the code and keep it in your head.<p>Even if that were true, the code I write is better for having written the comments, especially interface comments, because the writing helps my thinking. Moreover, it helps my code reviewers—without written interfaces. If all you have is the code and not a description of what the code is supposed to do, how can you know if it is correct? I think most code reviewers are verifying the code against what they infer the interface to be. It helps us both to just be explicit.<p>[1]: <a href="https:&#x2F;&#x2F;qntm.org&#x2F;clean" rel="nofollow">https:&#x2F;&#x2F;qntm.org&#x2F;clean</a>
sam_bishop3 个月前
One of my beefs with Clean Code is its name.<p>There is no objective measure of code cleanliness. So if &quot;clean code&quot; is your goal, then you have no meaningful criteria to evaluate alternatives. (Including those pitched by Bob Martin.)<p>It gets worse, though. There&#x27;s a subconscious element that causes even more trouble. It&#x27;s obviously a good thing to write &quot;clean code&quot;, right? (Who&#x27;s going to argue otherwise?) And to do otherwise would be a moral failing.<p>The foundation on which &quot;Uncle Bob&quot; tries to build is rotten from the get-go. But it&#x27;s a perfect recipe for dogmatism.
评论 #43172345 未加载
zbentley3 个月前
It&#x27;s striking to me how out of touch Martin seems to be with the realities of software engineering in this transcript. Stylistic refactors that induce performance regressions, extremely long and tortured method names for three-line methods, near-total animus towards comments ... regardless of who is right&#x2F;wrong about what, those takes seem like sophomoric extremism at its worst, not reasoned pragmatism that can be applied to software development in the large.<p>When I encounter an Uncle Bob devotee, I&#x27;m nearly always disappointed with the sheer <i>rigidity</i> of their approach: everything must be reduced thus, into these kind of pieces, because it is Objectively Better software design, period. Sure, standard default approaches and best practices are important things to keep in mind, but the amount of <i>dogma</i> displayed by folks who like Martin is really shocking and concerning.<p>I worry that his approach allows a certain kind of programmer to focus on like ... aesthetic, dogmatic uniformity (and the associated unproductivity of making primarily aesthetically-motivated, dogmatic changes rather than enhancements, bugfixes, or things that other coders on a project agree improves maintainability) instead of increasing their skills and familiarity with their craft.<p>Maintainability&#x2F;appropriate factoring are subjective qualities that depend a lot on the project, the other programmers on it, and the expectations around how software engineering is done in that environment.<p>Pretending that&#x27;s not true--that a uniform &quot;one clean code style to rule them all&quot; is a viable approach--does everyone involved a disservice. Seasoned engineers trying to corral complexity, new engineers in search of direction and rigor, customers waiting for engineering to ship a feature, business stakeholders confused as to why three sprints have gone by with &quot;refactor into smaller methods&quot; being the only deliverable--everyone.
评论 #43168907 未加载
评论 #43169794 未加载
评论 #43167342 未加载
评论 #43167689 未加载
评论 #43168118 未加载
评论 #43167480 未加载
评论 #43167228 未加载
评论 #43166969 未加载
评论 #43167478 未加载
评论 #43168962 未加载
评论 #43167672 未加载
评论 #43166932 未加载
bob10293 个月前
I&#x27;m currently dealing with one of those codebases representative of the consequences of blindly following &quot;Clean Code&quot;, et. al.<p>My experience has taught me that you never want to be the first person to recommend a rewrite. Since I am a mere contractor on this one, I am strongly inclined to let it unwind on its own. There seems to be a lot of ego embedded in those pointless data access layer wrappers. I&#x27;d hate to get on someone&#x27;s bad side right now. The market is quite rarified.
评论 #43172379 未加载
ilrwbwrkhv3 个月前
john ousterhout&#x27;s book is the only book on how to write software that has any actual evidence behind it. i highly recommend it as the only book to read on how to write code. and uncle bob, well, best to avoid his stuff as much as possible. clean code takes away about 5 years from every dev&#x27;s life as they think they need to read it to become an intermediate developer and one they realize that is not the way, can they finally grow.
评论 #43167069 未加载
评论 #43167233 未加载
评论 #43166840 未加载
评论 #43166959 未加载
coopykins3 个月前
As someone who&#x27;s recently started to read a philosophy of software design, I have to say that a lot of the points the author makes are things that I&#x27;ve come to learn with experience, which feels pretty good. As opposed to clean code, which I read when I was starting, and although at that time it felt good to have some guidelines—I still think having some guidelines is better than having nothing at all.<p>I think you grow out of that advice very soon, because it&#x27;s not very practical, it feels out of touch. The result is not code that is easier to read, quite the contrary. I think the Java world has been influenced for worse by him.<p>But I don&#x27;t have anything against him, as other comments say, the problem is dogmatism and trying to follow these authors blindly instead of thinking about it.
pnt123 个月前
Some software gurus really grind my gears, and Robert Martin is one of them. When confronted with bad advice he gave, he&#x27;s quick to say it&#x27;s not meant to be taken literally. Then, gurus like Kent Beck, say that you cannot criticize their approaches if you don&#x27;t implement exactly as they say. So, while this is not exactly a paradox (different people with different opinions), I feel like gurus make their livings on unfalsiable claims while shaping the world of software engineering.<p>So, some kudos to Robert for accepting criticism and discussing it, but no cigar for downplaying his own advice when confronted - I also recall a different discussion, where someone confronts his statement &quot;you don&#x27;t practice tdd you&#x27;re not a professional&quot;, and his answer &quot;it was not meant to be taken seriously&quot;.<p>These people had great ideas but they should be more critical of themselves, eg &quot;here&#x27;s when not to apply this&quot;, &quot;here&#x27;s where to bend this&quot;, not &quot;you&#x27;re doing it wrong&quot; or &quot;don&#x27;t take it literally&quot;.
评论 #43177756 未加载
评论 #43177637 未加载
wg03 个月前
The arguments from staunch clean code zealots have wasted so much time on PRs that I have lost count. Hours and hours and sometimes weeks - PRs having ideological discussions on something that neither the underlying machine cares nor the end user.<p>Multiply that across the industry and that probably easily reaches in hundreds of millions of dollars productivity wasted.<p>Ps: Not advocating cowboy coding or spaghetti code either.
loganmhb3 个月前
Plenty of people are ragging (justifiably) on Clean Code, but I really admire by contrast Ousterhout&#x27;s commitment to balanced principles and in particular learning from non-trivial examples. Philosophy of Software Design is a great and thought-provoking read.
评论 #43176618 未加载
dgunay3 个月前
I find it funny how much people obsess over Clean Code. In my opinion Robert Martin&#x27;s Clean Architecture is a much more valuable and realistic idea than all this madness about 3 line functions, no comments, do one thing, etc. I would take the ugliest code that followed Clean Architecture over any &quot;Clean Code&quot; that didn&#x27;t bother sensibly separating business logic and I&#x2F;O.<p>I don&#x27;t like the guy very much, but for web development even just mostly following Clean Architecture does so much to keep things from devolving into chaos long term.
WalterBright3 个月前
One method of commenting that has paid off for me the most was inserting links to:<p>1. the online documentation of the function being called<p>2. the instruction documentation for an instruction being generated, inserting<p>3. the issue that the code fixes<p>4. the specification of what the function is trying to implement<p>Then I fixed my text editor to enable click on those links.
评论 #43167635 未加载
ad_hockey3 个月前
Something I find odd about Uncle Bob&#x27;s style is the preference for reading and modifying shared state over pure functions that take args. It makes me do a double take when I read a method registerTheCandidateAsPrime() (taken from UB&#x27;s rewrite) that doesn&#x27;t take a candidate arg.<p>How would you unit test those methods? You&#x27;d have to directly set the field values, then call the method, then assert on the fields. If the answer is &quot;you don&#x27;t unit test private methods&quot; then that&#x27;s completely fine, because I agree with that (perhaps this is implicit from the private keyword, I don&#x27;t know Java). But I&#x27;m struggling to imagine how you would get to those private methods with such a strict adherence to TDD as Bob recommends. Methods like increaseEachPrimeMultipleToOrBeyondCandidate() are quite complex, and would be tricky to build up using TDD if you couldn&#x27;t exercise them directly.<p>If nothing else, surely Bob&#x27;s approach is not thread safe. Call PrimeGenerator3.generateFirstNPrimes() concurrently and they&#x27;ll trample all over each other. John Ousterhout&#x27;s stateless version doesn&#x27;t have that problem.
hakunin3 个月前
For anyone like me who at first skipped over this article because it seems from the title that someone just compared two approaches:<p>No, it’s an actual debate between the actual John and Bob. Them debating each other. It’s an amazing read.
mkoubaa3 个月前
I can just tell that John Ousterhout works with much better developers on average than UB and that probably informs their biases.
评论 #43167175 未加载
bonsaiKiller3 个月前
There’s obviously a balance. Having worked in both environments, I tend to appreciate the code of someone who at least read the books, but treats it as suggestion rather than gospel. Contrast to someone who never read the books, has no clue what’s “good” and hacks everything.<p>On the one hand, the books are popular because a lot of people reading them think it makes a good point, and share that view. On the other hand, just because something is popular doesn’t make it right! I think this is where AI gets so much wrong. GIGO! If you base all your code on whatever is most common, are you really really sure that common pattern is really the best? AI, and these book evangelist, often have no clue. Just parroting others.<p>I’d rather deal with “principles” as opposed to “rules” every time. Glean the principles from the books, and at least try to write clean code!
samiv3 个月前
Instead of &quot;Clean Code&quot; I&#x27;d really suggest people read either<p><pre><code> - Code Complete - The Pragmatic Programmer </code></pre> <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Code_Complete" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Code_Complete</a><p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;The_Pragmatic_Programmer" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;The_Pragmatic_Programmer</a>
评论 #43170535 未加载
评论 #43171748 未加载
namuol3 个月前
I’ve come full-circle back to my junior engineer attitude with respect to coding “best practices”: Avoid anything resembling dogma.
beryilma3 个月前
&quot;Uncle Bob&quot; is not a software engineer (as he calls himself) and anything he says on the subject is theoretical at best, and snake oil at worst. Can anyone point to any substantial piece of code that he wrote before he can be taken seriously. The code pieces at his GitHub repos, other than style, etc., are just simplistic stuff.<p>It is probably OK to be thinking on issues related to a field (i.e., software engineering) without being a practitioner in the field, but producing fads-du-jour and selling them as solid (pun intended) theories and expecting to be taken seriously is just ludicrous to me.
ptx3 个月前
I&#x27;m surprised that Ousterhout doesn&#x27;t point out the huge problem introduced with the PrimeGenerator3 refactor: It stores state in static (!) fields, so it&#x27;s completely unusable in the presence of threads, unless you add a global lock.<p>Even if Uncle Bob thinks tiny methods are great, why would he introduce the pseudo-constructor &quot;initializeTheGenerator&quot; and make everything static if he needs state? If the helper methods were instance methods instead, the static &quot;generateFirstNPrimes&quot; method could simply construct a new instance to store the state.
LunicLynx3 个月前
The example they use is irrelevant. A solved problem can be written how ever one likes.<p>Code that will change or can’t ever be considered final, is the real challenge.<p>Overly cutting code into methods makes code just rigid. This could be the point, I guess, but if you need to change the methods name in order to reflect the methods intent, than you just wrote the classic unhelpful comment of:<p>&#x2F;&#x2F; check a is not null<p>if (a != 0) { … }<p>Overuse of comments has the same issue as overuse of methods.<p>Without rigor, comments and methods names will start to lie.<p>Because their content &#x2F; name weren’t necessary to understand the code. And should just not exist in the first place.
0xbadcafebee3 个月前
&gt; For me, the fundamental goal of software design is to make it easy to understand and modify the system. I use the term &quot;complexity&quot; to refer to things that make it hard to understand and modify a system.<p>This explains everything that&#x27;s wrong with modern software.<p>When you design a Formula 1 race car engine, the purpose of engine design is not to &quot;make the engine easier to modify&quot;. It&#x27;s to win races. And that depends on the race - a funny car engine, a formula 1 engine, a LeMans engine, Nascar engine, etc, are all different because the races are different.<p>Another example: when you design a building, the goal isn&#x27;t to make it easier to understand the building. The goal is to meet the requirements of the building, its uses, requirements, environment, etc. Sometimes a better building is just more complicated, and making the architect or builders&#x27; jobs easier, while nice, isn&#x27;t the goal.<p>Some things aren&#x27;t supposed to be easy to understand, because ease of understanding is not the goal of the thing. Focus on the real goal of the thing, and achieving that; don&#x27;t get distracted by ancillary goals.
评论 #43175878 未加载
评论 #43174848 未加载
评论 #43174381 未加载
评论 #43192153 未加载
评论 #43183236 未加载
blt3 个月前
The prime number code hurts to read. I feel like Bob is living in a different reality than most of us.
评论 #43178114 未加载
jjice3 个月前
Lots of negative comments about Uncle Bob in this thread. I personally didn&#x27;t like Clean Code and really enjoyed A Philosophy of Software Design, but I do think that some of his other books are really solid.<p>I accept that non-fiction books on anything will oversell the value of their way, and try to take what I can at a more moderate level. Through that lens, Clean Code didn&#x27;t give me much, but Clean Architecture did. The Clean Coder is also an interesting read on professionalism in software, and Clean Agile is an interesting read on Agile roots. I don&#x27;t know anyone that practices &quot;true&quot; agile (nor do I care to do so myself), but there are some really solid ideas in there.<p>I get that Clean Code kind of had a cult-like following in that people followed it blindly, but damn some of these comments are just rude about Uncle Bob. I still think he&#x27;s a pretty good author and has given me some advice through his other books that helped me a lot as a fresh faced dev.
评论 #43177683 未加载
vishnugupta3 个月前
While on this topic, one book I really enjoyed is &quot;Beautiful Code&quot;[1]. It is not preachy or prescriptive but a diverse set of programmers showing the code they enjoyed writing.<p>[1] <a href="https:&#x2F;&#x2F;www.goodreads.com&#x2F;book&#x2F;show&#x2F;405790.Beautiful_Code" rel="nofollow">https:&#x2F;&#x2F;www.goodreads.com&#x2F;book&#x2F;show&#x2F;405790.Beautiful_Code</a>
aswerty3 个月前
While I enjoyed the discussion as an exercise in stripping back positions to underlying principles. I find it a great irony that the overarching reason why they diverge on what is &quot;good practice&quot; is not discussed.<p>John sounds like he is about to start building a new type of database, and Bob sounds like he&#x27;s knee deep in a 20 year old code base for a logistics company. Both of their positions are reasonable, and both optimized for specific contexts.<p>I found Bob&#x27;s responses more measured (which I value a lot), with John&#x27;s at times being more compelling. I do agree that over-composition is a real problem that Bob is on the wrong side of the line on. But to be fair, Bob and Clean Code comes from a time where it was the opposite and his position on this feels like a philosophy that has an over-correction (albeit - not necessarily a flaw) at it&#x27;s core.
spacechild13 个月前
IMO the &quot;PrimeGenerator&quot; example from Clean Code is horrendous and completely unreadable! This would be so much better as a single method&#x2F;function with a few interspersed comments that explain the algorithm. I mean, just look at this abomination:<p><pre><code> private static boolean isMultipleOfNthPrimeFactor(int candidate, int n) { return candidate == smallestOddNthMultipleNotLessThanCandidate(candidate, n); } </code></pre> Not only is the method itself completely pointless, it also happens to have side effects! Who would expect this from the method name? So much for self-documenting code... Ousterhout rightfully calls him out on this bullshit.<p>In fact, Ousterhout makes such great points that I really want to read his book. Conversely, I&#x27;m now even less inclined to read Clean Code.
评论 #43178167 未加载
lynguist3 个月前
This was such a riveting and literary read, I enjoyed it and couldn’t put it away, like a novel where I was invested in the characters!<p>Are there any other such reads in the software engineering field?
评论 #43171168 未加载
评论 #43175636 未加载
jillesvangurp3 个月前
They are both mostly right but the devil is in the details and to try to not get too dogmatic about things. For example function length is one of those things that you can obsess about and debate endlessly.<p>What&#x27;s the value of extracting a function that is used only once or twice. It&#x27;s probably very limited. It&#x27;s debatable whether that even should be a public function and whether you should encourage more use. And then we can look at the function declaration as well. Does it have a lot of parameters? Is there any complexity to its implementation? Does it have tests? Are there going to be lot of uses of the function? If the answer to all those questions is no, you could probably inline it without losing much. But the flip side is that you wouldn&#x27;t gain much by doing so. A small function that is used a lot is probably somewhat valuable.<p>And there&#x27;s a third thing that needs to be considered: does a function increase the API surface of your module. Having lots of private functions makes your module hard to understand. Having lots of public functions, makes the API less cohesive.<p>So, there&#x27;s a grey area here. Languages like Kotlin give you a additional options: make it a nested function, make it an extension function, put it in a Companion object, etc. You can put functions in functions and those can help readability. The whole point of doing that is preventing usage outside the context of the outer function. Nested functions should probably be very short. And their only goal should be to make the outer function logic more readable&#x2F;understandable. It&#x27;s not something I use a lot but I&#x27;ve found a few uses for this. There&#x27;s no point to using nested functions other than for readability.<p>And speaking of Kotlin, it&#x27;s standard library is full of very small extension functions. Most of them are one or two lines. They are clearly valuable because people use them all the time. You get such gems as fun List.isNullOrEmpty(): Boolean which helps make your if statements a lot more readable and less flaky. Also works on Java lists. Stuff like that is a big part of why I like Kotlin.<p>I tend to dumb down a lot of advice like both are debating here to cohesiveness and coupling. In the context of functions, you get coupling via parameters and side effects (e.g. modifying state via parameters) instead of return values. And you lose cohesiveness if a single function starts doing too many not so related things. High coupling and low cohesiveness usually means poor testability. You&#x27;ll find yourself mocking parameters just to be able to test a function. Improving testability is a valid reason for extracting smaller, easier to test functions.
Applejinx3 个月前
It&#x27;s always fascinating to me to see this subject talked about, because I&#x27;ve been programming for years in a niche field (audio plugin DSP development) and have interacted with Clean Code programmers, but I seemingly cannot grasp what they do at all.<p>This is to the point that, in order to program and do the things I want to do, I have to essentially write nearly everything out longhand, to the point of unrolling things in repetitive fashion, and organizing things in blocks of code separated by comments about what&#x27;s being done in each block. I can do this so predictably and regularly that my code gets parsed by other people&#x27;s more Clean Code and ingested as sort of blocks of program behavior to be used in other software, to the point where it&#x27;s an 886-star repo with 79 forks: not Bob-scale, but then I haven&#x27;t written books or revolutionized corporate coding.<p>I&#x27;ve had to learn useful things about where my approach doesn&#x27;t take advantage of its hypothetical strengths: heedlessly unrolling everything doesn&#x27;t give you speed boosts, and I&#x27;ve had to learn to declare variables nearer to where they&#x27;re used. But I&#x27;ve also had to learn that I could do the opposite of Clean Code for performance gains. Back in the day, you could assign variables for calculations to avoid Repeating Yourself, but on modern processors it turns out… in addition to techniques like running calculations in parallel on wide data words that contain different data processed together… you can even take advantage of how eager CPUs are to do math, to avoid creating extra variables. It can be more efficient to just do the math a couple times rather than create a whole new variable just to skip the math.<p>This world makes sense to me. It acts like assembly language, except it&#x27;s C (not even C++). I don&#x27;t know to what extent there are other people who think this way, or struggle to keep track of even simple abstractions.<p>It&#x27;s just the context with which I see Bob acolytes, rather than just declaring a variable to not do the math twice, breaking it off into about twelve different methods for seemingly purely semantic reasons, and insisting anything else is stupid. And there I am, producing and re-using reams of shockingly primitive code that seems to work and where I can return to it, even a couple decades later, and have no trouble figuring out what I did.<p>There&#x27;s something to be said for being SO stupid that your work just works.
emtel3 个月前
Related: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27276706">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27276706</a>
nadam3 个月前
I was just thinking about what AI assisted coding brings to the design discussion, especially as AI become more and more powerful and we rely on it more and more. You still want to make things modular and easy to understand so that AI understands it easily and the needed info to modify a module can fit in a relatively small context window, but the difference is that it is very easy to make large scale measurement about which code style is understood better by an LLM, so maybe some of these debates will be decided relatively objectively!<p>For the topic: the discussed topics are relatively trivial surface level stuff, mostly I agree with POSD, but these will be handled by AI anyway. I guess humans will use the spare brain capacity to deal with the real deep design questions (for a while).
nickm123 个月前
buried at the end: there&#x27;s a planned second edition of Clean Code! Given Bob&#x27;s intransigence in this conversation, I wonder what he&#x27;ll change.
ArchieMaclean3 个月前
My take on the prime example:<p><pre><code> import itertools def generate_n_primes(n): &quot;&quot;&quot; Generate n prime numbers using a modified Sieve of Eratosthenes. The algorithm keeps track of a list of primes found so far, and a corresponding list of &#x27;multiples&#x27;, where multiples[i] is a multiple of primes[i], (multiples[i] is initially set to be primes[i]**2, see the optimisations section below). The main loop iterates over every integer k until enough primes have been found, with the following steps: - For each prime found so far - While the corresponding multiple is smaller than k, increase it by steps of the prime - If the multiple is now the same as k, then k is divisible by the prime - hence k is composite, ignore it. - If, for EVERY prime, the multiple is greater than k, then k isn&#x27;t divisible by any of the primes found so far. Hence we can add it to the prime list and multiple list! There are a few optimisations that can be done: - We can insert 2 into primes at the start, and only iterate over every odd k from there on - When we&#x27;re increasing the multiple, we can now increase by 2*prime instead of 1*prime, so that we skip over even numbers, since we are now only considering odd k - When we find a prime p, we add it to the prime and multiple list. However, we can instead add its square to the multiple list, since for any number between p and p**2, if it&#x27;s divisible by p then it must be divisible by another prime k &lt; p (i.e. it will be caught by an earlier prime in the list) &quot;&quot;&quot; # Insert 2 into primes&#x2F;multiples primes = [2] multiples = [4] # Iterate over odd numbers starting at 3 for k in itertools.count(3, 2): # If we&#x27;ve found enough primes, return! if len(primes) &gt;= n: return primes # For each prime found so far for i in range(len(primes)): # Increase its corresponding multiple in steps of 2*prime until it&#x27;s &gt;= k while multiples[i] &lt; k: multiples[i] += 2 * primes[i] # If its corresponding multiple == k then k is divisible by the prime if multiples[i] == k: break else: # If k wasn&#x27;t divisible by any prime, add it to the primes&#x2F;multiples list primes.append(k) multiples.append(k ** 2) return primes </code></pre> Some might find the docstring as well as comments too much - I find the comments help relate the code to the docstring. Open to suggestions!
pcblues3 个月前
On reflection, my attitude to books like these indicated where I was in my understanding of programming. They used to be useful life-buoys that one clung to for dear life early in one&#x27;s career in a fast-moving and often-changing industry. Then they become an interesting side-note reminding one of what they clung to as the good precepts that served them well stand out from the rest of the books. And finally they become unnecessary and seemingly dogmatic when one has become adept at swimming. In other words, essential reading depending on where you find yourself :) Disclaimer: out of these two, I only read Clean Code.
jdmoreira3 个月前
Uncle Bob probably the biggest scammer in Software. What a complete pile of garbage. So much energy wasted in all these design patterns, SOLID and other OOP bullshit.<p>Turns out you can just pass immutable data in and get immutable data out. Who would have guessed? The whole 90s - 00s Java OOP garbage still gives me nightmares
评论 #43192263 未加载
dionian3 个月前
&quot;That&#x27;s a valid concern. However, it is tempered by the fact that the functions are presented in the order they are called. Thus we can expect that the reader has already seen the main loop and understands that candidate increases by two each iteration.&quot;<p>I think this missed the point entirely. If i had to read the entire code to understand the behavior of that method, then is it really cleaner? Side-effects are evil
ptx3 个月前
UB says at one point:<p>&gt; <i>Would that we had such a crystal ball</i><p>And then it seems like he actually found his crystal ball, because in the very next question he refers to things that have not yet occurred in the conversation:<p>&gt; <i>interpreting your rewrite (below)</i><p>And later:<p>&gt; <i>In your solution, which we are soon to see below</i><p>This makes it somewhat confusing to read, with answers being based on counterpoints that will only have been made in the future. (Which, I suppose, is similar to the problem Ousterhout has with UB&#x27;s PrimeGenerator example.)
ben303 个月前
The primary goal of software design should be to facilitate understanding and modification for future developers, emphasizing the importance of code readability.
__mharrison__3 个月前
This is actually a great read.<p>I&#x27;m in the middle of designing a course for a client on teaching software engineering best practices for data scientists (and folks who live in Jupyter all day).<p>There seems to be a huge lack of material for these types that aren&#x27;t &quot;programmers&quot;, don&#x27;t live in an &quot;IDE&quot;, and are essentially writing code all day.
jpitz3 个月前
&quot;Do One Thing&quot; is to me maybe best understood in the context of the Single Layer Of Abstraction Principal - it has helped me numerous times to be very intentional about following SLAP in complex code, and Do One Thing seems to fall very naturally out of it.
kragen3 个月前
Crucial context here: Ousterhout is one of the great programmers who built the free software world we live in today, and Uncle Bob is a faker. Ousterhout is not without his problems (Stallman famously called him a &quot;parasite&quot; on the free software community, as well as fervently disagreeing with his technical taste) but he&#x27;s written truly world-changing software. By contrast, Uncle Bob is a windbag book author who has never managed to write any software worth using, to my knowledge.<p>Ousterhout to Uncle Bob:<p>&gt; <i>maybe you were surprised that it is hard to understand, but I am not. Said another way, if you are unable to predict whether your code will be easy to understand, there are problems with your design methodology.</i><p>This debate is full of treasures like this. What a brilliantly clear and understated way to expose charlatanism!<p>What is this “world-changing software” I&#x27;m saying Ousterhout has shipped? Tcl. (Hold on, now, don&#x27;t downvote just yet.) Tcl has been a crucial enabling technology for EDA and automated regression testing since literally the 01980s. Probably every VLSI chip in the computer you&#x27;re reading this on was designed, verified, and tested with workflows involving unholy amounts of Tcl. GCC&#x27;s test suite is also Tcl. Still.<p>Automated testing in the 01980s? Yes. It&#x27;s true that automated testing wasn&#x27;t very prevalent in the software world until the Agile guys (Uncle Bob and his less incompetent compatriots) popularized it around the turn of the century, but EEs and compiler engineers have been pervasively automating testing a lot longer than that, and Tcl was for a long time the least awful option, believe it or not. And that was John Ousterhout&#x27;s doing.<p>Do you know what the SPICE developers did to make SPICE scriptable, before there was Tcl? They linked csh into it. Motherfucking <i>csh</i>. If you&#x27;ve never tried to maintain a large script in csh, you do not know the meaning of suffering.<p>Good programmers write good software; bad programmers write bad software, or no software. Ousterhout has written one of the few pieces of software that can be called great. (In its historical context. In 01978 csh was great software too.) What software has Uncle Bob written?<p>Listening to Uncle Bob&#x27;s programming advice over Ousterhout&#x27;s would be like listening to your middle-school English teacher&#x27;s writing advice instead of Stephen King&#x27;s. It&#x27;s not that King could never give you worse advice, but if you need your English teacher&#x27;s advice, generally your judgment will not be good enough to distinguish the rare occasions King gets it wrong.
评论 #43177120 未加载
评论 #43174794 未加载
ninetyninenine3 个月前
Cleanliness AND Design is Highly correlated with IO, side effects and state.<p>Most programmers know about this in 2025 but they didn&#x27;t back then. Looks like the authors don&#x27;t even mention it.
zzzeek3 个月前
I&#x27;ve been programming since the early 80s and have never seen real world, production code that was done in so-called &quot;clean code&quot; style
okaleniuk3 个月前
It&#x27;s sad that we demoted the field from engineering to philosophy. But it is what it is.<p>Next step - fashion and belief.
评论 #43171198 未加载
评论 #43171142 未加载
de6u99er3 个月前
Clran code is just one of the tools in a good software engineer&#x27;s toolbox.
Hasu3 个月前
&gt; I bemoan the fact that we must sometimes use a human language instead of a programming language. Human languages are imprecise and full of ambiguities. Using a human language to describe something as precise as a program is very hard, and fraught with many opportunities for error and inadvertent misinformation.<p>This quote from Uncle Bob is shameful, considering that he has made 100% of his career on writing <i>English</i>, not code.
评论 #43173432 未加载
sharas-3 个月前
Whoes uncle is he anyways?
myst3 个月前
Where can I find Martin’s code? I would like to see and compile it.
评论 #43169428 未加载
tdiff3 个月前
Is there still any apologet of Bob Martin nowadays?
pjmlp3 个月前
All great, but generaly useless in most big corp project with offshoring, where we are already happy that we actually delivered something that works in first place.
mschoenert2 个月前
This prime generating code has fascinated me for a while.<p>It was first described by E.W. Dijkstra &quot;Notes on Structured Programming (EWD249), 2nd; 1970; TH Eindhoven&quot;. <a href="https:&#x2F;&#x2F;www.cs.utexas.edu&#x2F;~EWD&#x2F;ewd02xx&#x2F;EWD249.PDF" rel="nofollow">https:&#x2F;&#x2F;www.cs.utexas.edu&#x2F;~EWD&#x2F;ewd02xx&#x2F;EWD249.PDF</a><p>And then reformulated by D.E. Knuth &quot;Literate Programming; 1984&quot; <a href="http:&#x2F;&#x2F;www.literateprogramming.com&#x2F;knuthweb.pdf" rel="nofollow">http:&#x2F;&#x2F;www.literateprogramming.com&#x2F;knuthweb.pdf</a><p>Both use it to demonstrate their way of deriving and documenting an algorithm.<p>And then R. Martin used it again in his book &quot;Clean Code; 2008&quot;. (Though I&#x27;m not 100% certain what he wants to demonstrate with his rather difficult formulation.)<p>For the sake of this email I am going to call it &quot;Dijkstra&#x27;s algorithm&quot;.<p>If we look at it from an engineering perspective, then Dijkstra&#x27;s algorithm is never the best choice (at least not in 2025).<p>If performance is not the most important aspect, e.g. if we need less than 100000 primes, then the straightforward trial division is just as fast - and soooo much simpler (basically impossible to get wrong). Note that this is different in 2025 than it was in 1970, back then multiplications and divisions were much more expensive so it made sense to minimize them.<p>If performance is the most important aspect, then the sieve of Eratosthenes is much faster. And you can implement the sieve with a sliding window, which is just as fast (or even a bit faster because of caching) and uses a bounded amount of memory.<p>Concretely - my implementation of the sliding window sieve of Eratosthenes is about 50 times faster than Dijkstra&#x27;s algorithm (on the same machine) when generating the first 200 million primes (7.5 sec vs 6 min).<p>The reformulation - both by Ousterhout and Martin - computes multiples for every new prime found. This will quickly lead to overflow, e.g. the 6543-th prime is 65537, so its square will overflow 32 bit unsigned integers. Dijkstra&#x27;s formulation on the other hand only computes multiples that are actually used to filter, the multiples are never (much) larger than the candidate.<p>Note that computing the multiples so eagerly will also make the multiples vector unnecessarily large (wasting memory).<p>Knuth and Dijkstra both remark that there is a subtle problem with the correctness of the algorithm. When incrementing lastMultiple and then later accessing primes[lastMultiple] und multiples[lastMultiple] it is not obvious that those will already be assigned. In fact they will be, but it is very difficult to prove that. It is a consequence of the fact that for every integer n there is always a prime between n and n*n, which follows from Betrand&#x27;s theorem, a difficult number-theoretical result.<p>So if you look at Ousterhout&#x27;s and Martin&#x27;s reformulation and think &quot;a yes - now I get the algorithm&quot;, then beware: You&#x27;ve missed at least two aspects that are relevant for the algorithm&#x27;s correctness. ;-)
cjfd3 个月前
PDSD is correct on length of methods. The methods given in an example in CC are ridiculously short. CC is more correct on comments than PDSD. Especially mandating comments in certain places leads to very low quality and, frankly, utterly disgusting comments point out, helpfully that the &#x27;get_height&#x27; method &#x27;gets the height&#x27;. CC is more correct on TDD than PDSD. The noticed danger of just focussing on implementation details over the structure of the API is always there but TDD has a refactor step to fix that. The general idea of working in small steps with there being a safe state between every small step is worth its weight in gold.
MetaWhirledPeas3 个月前
I think the reason most people have a problem with Uncle Bob is because they know their own practices are a far cry from his recommendations, and they take his prescriptive and uncompromising advice as a personal attack.<p>I also wonder how many people interpret his advice as that of a mindless, pedantic dictator.<p>My own introduction to UB was from some random YouTube video he made about programming languages, so my first impression of him included his humor and his ability to see both sides of an issue while being unafraid of having a strong opinion. I really enjoy speaking with and listening to people with strong, long-marinated opinions, regardless of whether I agree or not. At the very least it means they&#x27;ve put a lot of thought into it, which makes for better discussion and learning.<p>I also lack a long history of code commits, being more of a dabbler here and there, so perhaps I have a smaller surface area for UB&#x27;s jabs to land upon. Still, I acknowledge that a Clean Code Nazi would probably rip me to shreds for some of the practices I&#x27;ve followed and some that I continue to follow. But <i>improvement</i> is a much more achievable goal than perfection, and gleaning valuable information is better than being dogmatic.<p>In the end I <i>love</i> listening to UB talk. I don&#x27;t follow all his practices but I <i>do</i> keep them in the back of my mind. If not worth following strictly they are always worth considering, especially the intent behind them.<p>So when I see his opinions on comments or his opinions on abstraction and variable naming my first instinct is not to lament about how he is poisoning our youth or insulting my code, but rather to ask myself how I can make use of his perspective. I&#x27;d encourage others to do the same; it&#x27;s much more fun that way, not just for programming but for everything.<p>As for those of you stuck in &quot;Clean Code&quot; hell with oppressive supervisors demanding strict adherence... that sounds like a personal failure, or a personal incompatibility, or both. I would blame the messenger there, not the message.
评论 #43179574 未加载
htk3 个月前
What a great discussion between two prominent figures in the field of software design. Thank you for posting this!
评论 #43171745 未加载