Those who know, know.
I’m of the opinion that Uncle Bob did some massive damage to software development as a whole with that book.
With that said, this is genuinely funny.Agreed. I found that many developers, in the pursuit of clean code, lost slight of some of the fundamentals principles of good code. I found that people were eschewing readability and modularity and calling it clean code.
Clean code became the target, not the underlying principles and the reason why we needed clean code in the first place. It became an entirely new thing that aided in producing some of the worst code I’ve read.
Oftentimes, when devs talk about “clean code” it’s a red flag for me in hiring. Some of the worst devs I’ve worked with have been clean code evangelists.
I’m beginning to feel we’re no longer talking about Clean Code being bad, but about people following ideas they don’t understand, which is not related or caused to any particular book.
I think its less about not understanding and more that these concepts only work in unrealistic scenarios that aren’t real. It’s the same with Agile. They never address the actual issue and try to work around them which never works.
I’d love to learn what that damage was. I often see complaints (sometimes also involving tech choices) but usually they’re not specific, so I’m always left wondering.
I’ve found it’s mostly two things: readability (ironically) and performance. I’ll describe a few crude examples, but I won’t get too much into specifics, otherwise I might as well write another book myself.
The performance part is simple: its excessive reliance on polymorphism and the presence of several levels of abstraction just doesn’t allow for good code generation. I’ve seen 10x+ performance improvements by dropping all of the above, with often minimal loss in readability; on the contrary, oftentimes the code became more readable as well.
The readability part is harder to explain; not only because it depends on the codebase and the problem at hand, but also on the coding style each programmer has (though in my opinion, in that particular case it’s the programmer’s problem, not the codebase’s).
I like to think of codebases as puzzles. To understand a codebase, you need to piece together said puzzle. What I’ve found with Clean Code codebases is that each piece of the puzzle is itself a smaller puzzle to piece together, which isn’t ideal.Functions
They should be small and do one thing
I generally disagree, not because those ideas are wrong, but because they’re often too limiting.
What often happens by following those principles is you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together. Your code loses locality and, much like with CPU cache locality, your brain has to do extra work to retrieve the information it needs every time it needs to jump somewhere else.
It may work for describing what the code does at a high level, but understanding how it works to make meaningful changes will require a lot more work as a result.Don’t repeat yourself
Once again, it makes sense in principle, but in practice it often creates more problems. I agree that having massive chunks of repeated code is bad, no questions about it, but for smaller chunks it may actually be desirable in some circumstances.
By never repeating code, you end up with functions that are over-parameterized to account for all possible uses and combinations that particular code snippet needs to work with. As a result, that code becomes more complex, and the code that calls it does too, because it requires you to know all the right parameters to pass for it to do the right thing.Exceptions
Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of.
The name itself is a misnomer in my opinion, because they’re rarely exceptional: errors are not just common, but an integral part of software development, and they should be treated as such.
Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.Classes, interfaces and polymorphism
I have lots of gripes with object orientation. Not everything needs to be an object, not everything needs to be polymorphic. There’s no need to have a
Base64Decoder, much less anIBase64Decoderor anAbstractBase64Decoder. Base64 only works one way, there are no alternative implementations, a function is enough.I’m a lot more on the data oriented side of the isle than the OO one, but I digress.
Object orientation can be good in certain contexts, but it’s not a silver bullet.Encapsulation for the sake of it
Let’s say you have something like this:
class Point { public float X, Y; }With the Clean Code approach, it magically becomes:
class Point { private float x, y; public float get_x() { return this.x; } public float get_y() { return this.y; } public void set_x(float x) { this.x = x; } public void set_y(float y) { this.y = y; } }Why? Who the hell knows. It makes absolutely no tangible difference, it only makes your code longer and more verbose. Now, if a value needs validation, sure, but oftentimes this is just done regardless and it drives me insane.
Abstract classes for everything!
- “You’ll never know when you’ll need to add another implementation, right?”
- “You don’t need to know the underlying implementation”
The problem with wanting to create the most generalized code in advance is that you end up stuck in abstraction hell.
You may as well not need the ability to have arbitrary implementations, but now you need to plan for that.Not only that, but it also makes reasoning about your code harder: how many times have you had to step through your code just to figure out what was being executed | just to figure out what particular concrete class was hiding behind an abstract class reference?
I myself, way too many, and there was often no reason for that.Also, the idea that you shouldn’t know about the implementation is crazy to me. Completely encapsulating data and behaviour not only makes you miss out on important optimizations, but often leads to code bloat.
There’s more but I’m tired of typing :)
Take a look at these if you want more info or someone else’s view on the matter, I wholeheartedly recommend both:
Functions should be small and do one thing […] you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together
I believe you have a wrong idea of what “one thing” is. This comes together with “functions should not mix levels of abstraction” (cited from the first blog entry you referenced). In a very low-level library, “one thing” may be sending an IP packet over a network interface. Higher up, “one thing” may be establishing a database connection. Even higher up, “one thing” may be querying a list of users from the database, and higher up yet again is responding to the
GET /usershttp request. All of these functions do ‘one thing’, but they rely on calls to a few methods that are further down on the abstraction scheme.By allowing each function to do ‘one thing’, you decompose the huge problem that responding to an HTTP request actually is into more manageable chunks. When you figure out what a function does, it’s way easier to see that the function
connectToDbwill not be responsible for why all users are suddenly called"Bob". You’ll look into the http handler first, and if that’s not responsible, intogetUsersFromDb, and then check whatsendQuerydoes. If all methods truly do one thing, you’ll be certain thatcheckAuthorizationwill not be related to the problem.Tell me if I just didn’t get the point you were trying to make.
Edit: I just read
Martin says that functions should not be large enough to hold nested control structures (conditionals and loops); equivalently, they should not be indented to more than two levels. He says blocks should be one line long, consisting probably of a single function call. […] Most bizarrely, Martin asserts that an ideal function is two to four lines of code long.
If that’s the standard of “doing one thing”, then I agree with you. This is stupid.
Yeah that was essentially what I was referring to (referring to your edit).
I generally dislike stuff like (crappy example incoming):
void do_stuff(int count, bool cond) { function1(count); function2(b); function3(); } void function1(int count) { for (var i = 0; i < count; i++) { ... } } void function2(bool cond) { if (cond) { ... } else { ... } } void function3() { ... }I’m not a fan of this kind of code fragmentation.
If all those actions were related and it could have been just one thing, retaining a lot more context, then it should be one function imo.
If by not splitting it it became massive with various disconnected code blocks, sure, but otherwise I’d much prefer being able to read everything together.If splitting the functions required producing side effects to maintain the same functionality, then that’s even worse.
Huh, I really like code like that. Having a multi-step process split up into sections like that is amazing to reason about actual dependencies of the individual sections. Granted, that only applies if the individual steps are kinda independently meaningful
To adapt your example to what I mean:
Baz do_stuff(int count, boolean cond) { Foo part1 = function1(count); Bar part2 = function2(cond); return function3(part1, part2); }This allows you to immediately see that part1 and part2 are independently calculated, and what goes into calculating them.
There are several benefits, e.g.:
- if there is a problem, you can more easily narrow down where it is (e.g. if part2 calculates as expected and part1 doesn’t, the problem is probably in function1, not function2 or function3). If you have to understand the whole do_stuff before you can effectively debug it, you waste time.
- if the function needs to be optimized, you know immediately that function1 and function 2 can probably run in parallel, and even if you don’t want to do that, the slow part will show up in a flame graph.
It really depends on the context frankly. I did say it was a crappy example ;)
Try to read this snippet I stole from Clean Code and tell me if it’s readable without having to uselessly jump everywhere to understand what’s going on:public class SetupTeardownIncluder { private PageData pageData; private boolean isSuite; private WikiPage testPage; private StringBuffer newPageContent; private PageCrawler pageCrawler; public static String render(PageData pageData) throws Exception { return render(pageData, false); } public static String render(PageData pageData, boolean isSuite) throws Exception { return new SetupTeardownIncluder(pageData).render(isSuite); } private SetupTeardownIncluder(PageData pageData) { this.pageData = pageData; testPage = pageData.getWikiPage(); pageCrawler = testPage.getPageCrawler(); newPageContent = new StringBuffer(); } private String render(boolean isSuite) throws Exception { this.isSuite = isSuite; if (isTestPage()) includeSetupAndTeardownPages(); return pageData.getHtml(); } private boolean isTestPage() throws Exception { return pageData.hasAttribute("Test"); } private void includeSetupAndTeardownPages() throws Exception { includeSetupPages(); includePageContent(); includeTeardownPages(); updatePageContent(); } private void includeSetupPages() throws Exception { if (isSuite) includeSuiteSetupPage(); includeSetupPage(); } private void includeSuiteSetupPage() throws Exception { include(SuiteResponder.SUITE_SETUP_NAME, "-setup"); } private void includeSetupPage() throws Exception { include("SetUp", "-setup"); } private void includePageContent() throws Exception { newPageContent.append(pageData.getContent()); } private void includeTeardownPages() throws Exception { includeTeardownPage(); if (isSuite) includeSuiteTeardownPage(); } private void includeTeardownPage() throws Exception { include("TearDown", "-teardown"); } private void includeSuiteTeardownPage() throws Exception { include(SuiteResponder.SUITE_TEARDOWN_NAME, "-teardown"); } private void updatePageContent() throws Exception { pageData.setContent(newPageContent.toString()); } private void include(String pageName, String arg) throws Exception { WikiPage inheritedPage = findInheritedPage(pageName); if (inheritedPage != null) { String pagePathName = getPathNameForPage(inheritedPage); buildIncludeDirective(pagePathName, arg); } } private WikiPage findInheritedPage(String pageName) throws Exception { return PageCrawlerImpl.getInheritedPage(pageName, testPage); } private String getPathNameForPage(WikiPage page) throws Exception { WikiPagePath pagePath = pageCrawler.getFullPath(page); return PathParser.render(pagePath); } private void buildIncludeDirective(String pagePathName, String arg) { newPageContent .append("\n!include ") .append(arg) .append(" .") .append(pagePathName) .append("\n"); } }That’s what I was talking about.
The “Don’t repeat yourself” mantra is also used with documentation, this leads to documentation which you first have to read and learn unless you frequently want to step into issues of the documentation assumed you read prior parts and didn’t just searched how to do XYZ.
Thank you for linking the blog posts. They are a really good deterrent from Clean Code. I once thought I’d read it, but Fowler’s advice really is stupid.
In case you’re wondering why I replied three times: “Do one thing” :)
The “Don’t repeat yourself” mantra is also used with documentation, this leads to documentation which you first have to read and learn unless you frequently want to step into issues of the documentation assumed you read prior parts and didn’t just searched how to do XYZ.
Also while I used the more clean code oriented XML DOM implementation for my D XML parser (or at least copied such code as it was abandoned by its original creator), I planned a much simpler system for my SDLang parser. While everything originates from the
DLElementabstract class, I didn’t go overboard with the interfaces, etc.I generally agree, but there are some things that are oversimplified. Sure a point(x, y) can have public attributes, but usually business objects are a bit more complex: insurancePolicy, deliveryRoute, user, etc. Having some control over those is definitely something you want to implement, at the cost of some boilerplate.
Oh for sure. I have nothing against getters and setters when they’re justified, but in the case of bare fields with no validation like that example it’s just annoying.
Also stuff like this just grinds my gears (oversimplified example again):class IntegerAdder { private int a, b; public IntegerAdder(int a, int b) { this.a = a; this.b = b; } public int get_sum() { return a + b; } }Just make it a bloody function.
You may say it’s silly, but I’ve genuinely found code like this in the wild. Not that exact code snippet of course but that was the spirit.
Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of. The name itself is a misnomer in my opinion, because they’re rarely exceptional: errors are not just common, but an integral part of software development
They may be a part of software development, but they should not be common during the normal execution of software. I once read the hint, “if your app doesn’t run with all exception handlers removed, you are using exceptions in non-exceptional cases”.
Throwing an exception is a way to tell your calling function that you encountered a program state in which you do not know how to proceed safely. If your functions regularly throw errors at you, you didn’t follow their contract and (for instance) didn’t sanitize the data appropriately.
Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.
I disagree here. You can always ignore an error return value and pretend that the “actual” value you got is correct. Ignoring an exception, on the other hand, requires the effort to first catch it and then write an empty error handler. Also (taking go as an inspiration), I (personally) find this very hard to read:
res, error = try_something() if error { handle_the_error(error) return_own_error() } res2, error2 = try_something_else(res) if error2 { handle_other_error(error2) return_own_error() } res3, error3 = try_yet_something_else(res2) if error3 { handle_the_third_error(error3) return_own_error() } return res3This code mingles two separate things: The “normal” flow of the program, which is supposed to facilitate a business case, and error handling.
In this example, on the other hand, you can easily figure out the flow of data and how it relates to the function’s purpose and ignore possible errors. Or you can concentrate on the error handling, if you so choose. But you don’t have to do both simultaneously:
try { res = try_something() res2 = try_something_else(res) res3 = try_yet_something_else(res2) return res3 } catch (e) { // check which error it is and handle it appropriately throw_own_exception() }Also (taking go as an inspiration), I (personally) find this very hard to read
Agreed. Go’s implementation of errors as values is extremely noisy and error prone. I’m not a fan of it either.
You can always ignore an error return value and pretend that the “actual” value you got is correct.
Then that’s a language design / api design issue. You should make it so you cannot get the value unless you handle the error.
I’m of the opinion that errors should be handled “as soon as possible”. That doesn’t necessarily mean immediately below the function call the error originates from, it may very well be further up the call chain. The issue with exceptions is that they make it difficult to know whether or not a function can fail without knowing its implementation, and encourage writing code that spontaneously fails because someone somewhere forgot that something should be handled.The best implementation of errors as values I’ve seen is Rust’s
Resulttype, which paired with the?operator can achieve a similar flow to exceptions (when you don’t particularly care where exactly an error as occurred and just want to model the happy path) while clearly signposting all fallible function calls. So taking your example:try { res = try_something() res2 = try_something_else(res) res3 = try_yet_something_else(res2) return res3 } catch (e) { // check which error it is and handle it appropriately throw_own_exception() }It would become:
fn do_the_thing() -> Result<TheValue, TheError> { res = try_something()?; res2 = try_something_else(res); res3 = try_yet_something_else(res2)?; } match do_the_thing() { Ok(value) => { /*Do whatever*/ } Err(error) => { /*handle the error*/ } }The difference is that you know that
try_somethingandtry_yet_something_elsemay fail, whiletry_something_elsecannot, and you’re able to handle those errors further up if you wish.
You could do so with exceptions as well, but it wasn’t clear.The same clarity argument can be made for
nullas well. AnOptiontype is much more preferable because it forces you to handle the case in which you are handed nothing. If a function can operate with nothing, then you can clearly signpost it with anOption<T>, as opposed to justTif a value is mandatory.Exceptions are also a lot more computationally expensive. The compiler needs to generate landing pads and a bunch of other stuff, which not only bloat your binaries but also prevent several optimizations. C# notoriously cannot inline functions containing
throws for example, and utility methods must be created to mitigate the performance impact.The best implementation of errors as values I’ve seen is Rust’s Result type
You’re talking Monads, baby!
lol
I should get to work on my opus, “Dirty Code”
Inside I’ll reveal all my secrets like: not writing tests, not documenting anything, putting the whole app into a single python file, object-disoriented relational mapping, obscure SQL tricks, unobscure no-sql tricks, and more!
object-disoriented
I’ll steal this to shit talk about code; until git blame points to my past self
Github, but it’s afraid of commitment, it just wants to spoon.
Just make sure the first chapter is dedicated to spaghetti, and contains various GOTO statements telling where the reader where to go shove it and other obscenities.
I hope your book won’t have a table of context and those stupid indexes. If they read it, they should know where you mention topics, right? Tables of contents considered harmful! /s
I hope the tricks are only supported on kafka’s ksql.
I like “how to build APIs you won’t hate”.
But is it rewritten in Rust?
It’ll be rewritten in mdBook
Closure! (I don’t think so, not many programmers like reading/writing functional code. But it is his current favorite language, so, who knows?)
Working in Ruby did 10x more to help me write clean code than reading Clean Code ever did.
Many of the lessons drilled into me with Ruby (keep a consistent style, tests are cheap, keep your methods relatively small where possible, reduce nesting where possible) carry over nicely into other languages without needing to go through any OO bullshit.
IMO, the best lesson around Clean Code is this: you’re not clever, write obvious code that works with as few tricks as possible.
I find this to be true for every new language I try out. Since every language has a different way of doing things and gives me a new perspective, in the long run they all end up improving my programming style as a whole. I always end up integrating the best parts of each into my next project when possible.
Experience will always be more valuable than any set of rules these kind of books tout as “the way things are meant to be done”.
The bit of Clean Code that I read was unimpressive, but Clean Architecture was amazing. I view that book as required reading for anyone who wants to write code professionally. If Uncle Bob hasn’t realized that his coding style is worse than alternatives, I do not see how a second version of the same bad ideas is going to do well.
New edition is just an incoherent rant about the “woke mind virus” trying to destroy him for “just saying what everyone is thinking”.
This! Uncle Bob is a garbage person. Used to really respect him, but F that guy.
I didn’t knew anything about him but I respect everyone who doesn’t shut up in front of the woke agenda and propaganda.
And what would you say is that “woke agenda and propaganda”?
Dude fuck off
“Code optimization is a cultural Marxist conspiracy!”
Is this a cute joke or is he being serious and oblivious?
Isn’t that the guy who caused the whole Factorio Kovarex controversy?
What kovarex controversy? Link? Context?
Don’t ask his opinions about the term “statutory rape”!
Had to dig around a little, but I think I got some context :
I don’t recall Uncle Bob being sexist or racist, but maybe I missed something.
During the George Floyd Protests, Robert gives us a beautiful take that police stopping black people isn’t racist, it’s just math.
oh no
Unfortunately a sizable portion of programmers and engineers are like this. It’s probably because they can only think in black and white.
A lot of these old-fashion types are oblivious to social justice and get upset at even the thought that Institutional racism even exists, because they can point to their one black friend in tech who owns a mansion.
I used to get into arguments why master and slave was a problematic word to engineers. That’s how ignorant they are.
Those folks are dying out, especially as more diversity exists. Which is humourous because these folks will also rage about that too.
Yes. I never looked at kovarex the same since.
I’m a programmer since the 80s, who is this guy?
Your long lost son, perhaps
He wrote for example the books Clean Code and Clean Architecture which are IMO opinion really good books although I don’t agree with every point he makes.
Some really good points he makes are for example:
- Functions that only do one job
- Testing makes refactoring easier
- The standard SOLID OOP stuff.
- Tech debt is bad
- Abstraction and encapsulation is good and allows developers to interact with the code on a higher level in terms of actions instead of writing verbose stuff. Essentially saying less code leads to less bugs
- Insulate yourself from change
- Duplication is bad
- Two use cases that are very similar is not duplication and common code shouldn’t be factored out.
- Don’t mix high level code with low level.
- Build solid Entity classes to model the data and their interactions.
- Don’t write multithreaded code if you don’t have to.
- If you have to do your best to write it so they don’t share memory.
Those comes with examples. He’s a tad bit overly idealistic in my opinion. These books fail to mention a couple of things:
- Refactoring is expensive and the cost is often not justified.
- Premature abstraction is the absolute devil
- You don’t need to insulate from things that are very unlikely to change (like going from SQL to Document DB)
- Less changes also lead to less bugs.
- Too much emphasis on functions being few lines of code instead of just being simple.
All in all though, very solid books. I read Clean Code in university and Clean Architecture in my first job and it really helped me wrap my head around different ways to solve the same problem. Excellent ideas but it’s not the holy truth. The only reason I remember all of these points is that I encountered all of them on the job and saw the benefit.
In my opinion new programmers should read it and take inspiration. Craftsman level developers should criticise and maybe pick up a few brain concepts to sort some concepts out in their brain. Experts will get little benefit though.
The consultancy I used to work for in the late 90s would have crucified any developer that didn’t write “a data abstraction layer that allows you to pop off the original db and substitute a different one later”.
How many times in my 25 year career have I swapped out the database (and been thankful for such an abstraction layer)? 0 times.
In my 15 year career? Dozens. Maybe low hundreds. Depends what you work on. Oracle is not making any friends lately and a ton of companies a whole-sale migrating to Postgres, MongoDB, DynamoDB or some of the NewSQL contenders. It’s like 50% of the projects I’m involved in. Results are generally positive, with some spectacular wins (x3000 acceleration or x1000 lower costs) and a few losses.
I am literally in the middle of swapping DynamoDB for a RDBMS.
The idea that you can abstract away such fundamentally different data stores is silly. While I hate doing it now, reworking the code to use relational models properly makes for a better product later.
I generally agree with the idea that code should be as simple as it can be to accomplish the goal of the code… I just haven’t been convinced that Clean Code is the way to get there, necessarily. The book does contain some good advice , to be sure, but I wouldn’t call it universal by any means.
I also think TDD is a very optimistic strategy that just doesn’t match up with reality terribly often.
Actually, I think that’s what confuses me the most about all of Uncle Bob’s books. I’ve read a couple of them and thought, “All this sounds great but real world development just doesn’t seem to work that way.” Like, all of his advice is for best case scenarios that I certainly haven’t encountered in my career.
I say confusing, because surely he’s been in the profession long enough to have seen the disconnect between what he’s preaching and real life, right???
Thanks for the warning
Glad I didn’t read it.
i guess this time the book involves a foreword in every chapter written by a woman that explains why they shouldn’t be allowed behind a computer
“A woman wrote that joke”
Dare I ask?
I don’t have any examples personally, but I’ve been told by a lot of people that he has some views about women, race, sex, homosexuality, etc which many would find objectionable.
Edit: his Twitter is pretty much 50% programming, 50% GOP politics. He might be a bit more progressive than your average Republican, but he still expresses a strong anti-left/anti-“woke” set of beliefs.
A true man of the 70s-80s…
hearsay
sigh I looked at his Twitter and it’s pretty standard right-wing politics. Maybe slightly more progressive than modern right-wingers, but still vomiting GOP propaganda.
ok, I’m left, but how’s that of any relevance.
if you can’t put a name or even quote an allegation, maybe you shouldn’t comment.
there are lots of intellectually dishonest people intentionally misrepresenting what others say in the hopes others - like yourself - parrot it just for likes and visibility.
It’s not exactly news, his invitation to a conference was pulled because every other speaker refused to share a stage with him over his behavior / the politics he spews on Twitter.
twitter happened, I guess
But today I stumbled across a long twitter thread that I can only describe as intentional character assassination. The author of this thread is misrepresenting facts and making some pretty nasty accusations. Again this is not all that unusual, except for the fact that I was not invited to defend myself. […] The gist of this author’s thread is that I am a misogynist; and that I should not be taken seriously in any regard. I understand that efforts have been made to have me excluded from conferences, and to boycott the publisher of my books, etc.
- Uncle Bob in 2017
This is just a lot about people’s reactions to something, but nothing about what that something actually was
It’d be nice to see what the actual something was so one could judge for themselves
Edit: I took a look at his twitter, and he seems to be pro-trump and anti-kamala and anti-walz, calling him a socialist who let Minneapolis burn, as well as transphobia thrown in here and there and more that I didn’t bother to read
…so I’m gonna go with “the people’s reactions to him likely had a point”
exactly, vague accusations in a lot of places, nothing remotely concrete.
…so I’m gonna go with “the people’s reactions to him likely had a point”
…and this is exactly the problem
You know what? You can find enough concrete shit from just reading his twitter for 5 minutes. Stuff posted in the last few weeks.
Hmm. The initial drama seems bullshit, starting a huge fight over the word “craftsmanship” is just hypersensitive at best or toxic behavior to manufacture outrage at worst. A gender neutral terms would be preferable but hardly the biggest issue right now.
But since “uncle bob” supports Trump then that alone is enough to condemn him as a supporter of fascism and bigotry.
Like what? Some L takes on wars or politics? Because that’s all I’m seeing.
ah yes, as we all know statistically these people tend to have a very sane opinion of women
So… What is the problem of women in tech? Either I skimmed over this or he fails to get to that point at all.
well, that’s up to women in tech to explain what the movement advocates for, he’s laying out his experience
Not even that, he’s basically using 1000 word essay to say “I can’t be a misogynist, I hired women” as if that says anything. The words “the problem with women in tech” are both mentioned many times in the article as well as its title, but somehow it’s not about that problem at all, but the fact he got called a misogynist and that he now has conflicted feelings about it.
Man, this is such a bad defence, let alone article.
Interesting, thanks, I didn’t know anything about that. I’ve probably looked at the book at some point, but don’t remember anything about it.
Now . After they’re done , they should write one for perl and brainf**k
Cleaner Code.
Waiting for him to finish the trilogy with Cleanest Code
cleanerer code. gotta leave room for a fourth book: clean code and the crystal skull
I was a big Uncle Bob fan and still really like the Clean Code book. But he trashed his public reputation so I doubt this 2nd edition will do very well.
Is there a TL;DR if I don’t know who this is?
Basically he is an old man/ software engineer who’s famous for his philosophy of coding.
Any context on him “trashing his reputation”?
I am also a big fan of his books, especially Clean Code. His (far-)right opinions are bad, but should be (to some extent) viewed separately from his technical standpoints. However, even then a new edition would not perform well, there are too many people hating Clean Code (without really understanding its message/just ranting without having read it). But I was very surprised that ThePrimeagen recently interviewed his “opponent”, it was very nice to watch.
