Beyond Clean Code

by pbw • 2 years ago

93 91 2 years ago

ilrwbwrkhv• 2 years ago

the problem with code is that the abstraction changes and data needs to be migrated:

e.g. a user is enabled if they have paid... time passes... now a user is enabled if the team they belong to has paid. now you need to move the logic to another struct / class and the data to another table.

now this is where "payables" and things come in and you start going the path of clean code with 1000 classes.

instead, the best way to do this is immutable data streams and event listeners.

after over a decade of programming, i feel for most software with a customer focus (not low level, embedded etc), immutable data streams where data flows through and listeners do things to themselves is the best way.

pezo1919• 2 years ago

Same conclusion here. May I ask about your stack/domain?

charlie0• 2 years ago

I fully agree, but this requires a certain level of experience to organize code in a way that makes it easy to navigate and modify. It's quite easy to end up with with "rube goldberg" code where you don't know what listeners are being triggered by what streams. Or to end up with a ton of edge cases where things aren't handled properly when issues occur.

leonseled• 2 years ago

Yea agree. I feel one of the best books ive read that makes this concrete is Grokking Simplicity by Eric Normand. It’s less about functional programming and more about functional thinking. Lots of concrete great advice in that book.

nateglims2• 2 years ago

Casey Muratori is basically describing Data Oriented Programming. Perhaps the most famous talk about it was from CPPCON 2014 [1]. I come from an embedded background (microcontrollers and bare metal) so I'm pretty sympathetic to his argument. If you work in it long enough, it feels natural and "clean". Uncle bob's Clean Code probably feels natural to Java devs.

Personally, my biggest gripe comes from experiencing people trying to introduce it to a team. Inevitably someone tries to enthusiastically implement some part of it and suddenly are writing 1 line functions everywhere. I think this is the type of thing Casey is also implicitly talking about when he's railing against the rules being brought up.

[1] https://www.youtube.com/watch?v=rX0ItVEVjHc

jpardy• 2 years ago

In addition to Mike Acton's talk, there is also the "DOD Book": https://www.dataorienteddesign.com/dodbook/

wiseowise• 2 years ago

Uncle bob's Clean Code probably feels natural to Java devs.

No.

tcfhgj3• 2 years ago

Don't see a problem with one line functions per se, especially if the name of the function helps understanding the code

arp242• 2 years ago

There no problem with them, and they can often be useful. But there is a problem if all the code is only functions of one or two lines, or when people move things to functions when it just doesn't make much sense, "because it's Best Practice™".

tetha• 2 years ago

Nah, short and single-line functions can be good.

Something I'm happy about is if I can create an object to implement some isolated part of the domain in a way that's obviously correct and consistent within itself. For example, currently I'm working on a bit of a backup analyzer to identify different problems, estimate sizes and such. One object in there is the PGBackrestState and it has a whole bunch of one-line methods like total_size_on_disk, full_backup_count, average_incemental_size. Most of these are just one list comprehension. That's nice, readable, correct and stable code - and it makes other code more readable.

But some functions in that code base are an implementation of pretty much a flow chart of grabbing information, figuring out the state of the system and eventually dropping into more specific analyzers. This can be a whole bunch of imperative code in a function. And I've tried, but chopping this into smaller functions makes the overall idea and control flow much harder to understand. Sometimes a rough screen length of logic can be easier to understand as well.

SatvikBeri• 2 years ago

My work has adopted DOD for roughly the last 3 years. Compared to OOP/FP[0], I would say DOD is generally more performant, more work to set up initially, harder to adapt to small changes, and easier to adapt to big changes.

DOD is generally going to have less in the way of user-defined classes/types. This can sometimes make it harder to convey the intent of the code, but in term it means there's a lot less to do if there's a big change in the problem domain – e.g. you don't have to refactor a whole class hierarchy.

Jonathan Blow has mentioned some ideas in his language Jai that would let you write code that can easily switch between OOP and DOD ideas, e.g. Array of Structs vs. Struct of Arrays, and I've seen that in some languages like Julia as well. I'm hoping it becomes more common place so that there's less of a tradeoff to make.

pbw9• 2 years ago

I’m not at all familiar with Julia but that sounds interesting. I’ve been thinking recently that with AI we might eventually decouple the style of the source code from the style of the executable code.

That is, let you toggle from DOD to OOP in your IDE. The way you can vary the font in your IDE today. Very non-trivial but in the long term could happen.

pbw9• 2 years ago

I think DOD is great and Casey’s optimized version is great. But his claim that OOP inevitably leads to horrible performance is factually wrong. And he’s repeats it over and over even after the viral video. My main goal with the article/video was to debunk this false claim of his.

Also, something most people over look is the OOP example in his article is 100% vanilla OOP. There is nothing “clean code” about it. So he’s really railing against OOP and not clean code.

My article shows that the impact of the overhead of OOP, but really the impact of the overhead of _anything_, can range from huge to basically zero, depending on the time scales involved. So my main point is you should be very mindful of the time scales involved.

But if you want to rule out OOP for non-performance reasons I think that’s fine. All styles have pros and cons, and situations can vary widely. Like for instance the existing style of the project and the skills and preferences of the people involved.

nateglims2• 2 years ago

I don't quite follow how you proved it wrong. All the examples seemed to be alternatives to OOP?

_aavaa_• 2 years ago

My article shows that the impact of the overhead of OOP ... So my main point is you should be very mindful of the time scales involved.

But if the overhead of OOP, as shown both by you and by Casey in his original video, makes up a significant chunk of your computation time it will inevitably lead to bad performance. Once you are mindful of the timescale and realize that OOP is the culprit, your only choice to go faster is to get rid of it.

KaiserPro• 2 years ago

I like this article. At the start I feared it was going to be one of those polemics written by someone who's never had to read other people's code, or worry about speed, efficiency or third party users.

However thats not the case. The author has distilled lots of experience into something reasonably readable.

Uehreka4• 2 years ago

So like, Clean Code really does say you should write four line functions, and does not put caveats on that statement, Uncle Bob even gives a lengthy terrible-looking example of a class written with 4-line functions and holds it up as the ideal. His views as expressed in that book are extreme and uncompromising, the “everything in moderation, there are many ways to write clean code” stuff is a rhetorical act he does when people call him out. Then when they’re gone and he thinks he can get away with it he starts speaking in absolute statements again.

Like, this is a conversation Uncle Bob had with Casey Muratori on GitHub, I came away feeling like Uncle Bob is more interested in playing rhetorical judo than anything else: https://github.com/unclebob/cmuratori-discussion/blob/main/c...

paulddraper• 2 years ago

Uncle Bob sounds good verbally.

Like "small functions." I say, okay, okay, stop writing these 2000 lines of spaghetti, I'm a hundred percent on board.

Then when you get to the concrete example, it's decomposing this 15 line function.

Good idea. Calibration is waaaay off.

booleandilemma• 2 years ago

He's the son of a pastor, he's definitely interested in rhetorical judo.

icholy4• 2 years ago

Has uncle Bob actually produced any useful software? Are there any examples of his work out there which can be analysed?

tcfhgj3• 2 years ago

People can give good insight about things despite even not creating these things, see e.g. physicists who study atoms

theLiminator• 2 years ago

Yeah, I get the impression that he just sells his image as some "guru" of software engineering, and that he doesn't actually deal with or write much real life code.

buescher3• 2 years ago

He’s got a GitHub. This seems to be the most notable thing: https://github.com/unclebob/fitnessedotorg

dakiol2• 2 years ago

Isn’t that the same case for Robert Martin? I’m not going to be the one defending Uncle Bob, but most of the people out there giving advice about “clean code/architecture” come from the consulting world without any work that can be analysed.

seadan836• 2 years ago

His career IIRC starts in the 70s. After 50 years, the answer is assuredly yes to the first question.

hirvi744• 2 years ago

I came away feeling like Uncle Bob is more interested in playing rhetorical judo than anything else

That's his only option.

I am not trying to speak ill of the man, but I am quite dubious of his advice.

I truly believe everyone has something to offer. However, I would feel more inclined to follow Uncle Bob's advice if he actually had the portfolio to back it up.

If Linus Torvalds were to give advice on how to build an operating system's kernel, I feel as though I should listen. Not only because Torvalds had/has good ideas, but because he also has demonstrable experience and work to back up his claims.

Uncle Bob has a lot of words, but projects speak louder.

taneq• 2 years ago

If Linus Torvalds were to give advice on how to build an operating system's kernel, I feel as though I should listen.

I'm pretty sure Linus' advice is 'don't be r***d'. In recent years he's learned a bit and now also would say 'don't be a c*t, probably, most of the time'. :P

rileymat2• 2 years ago

Perhaps the Uncle Bob principles do not create the best code, or most clear code, but more dogmatic adherence does make it harder to create the code I see on a daily basis that is so much worse and much more unmaintainable.

bishop_mortimer2• 2 years ago

I suppose if the options are "Uncle Bob's Rules" and the straw man of "No Rules" that could be true. That's like if you gave yourself the options of "one hand behind your back" or "two hands behind your back" in a fight when we already knew how to fight with "zero hands behind your back".

But I'm not sure I even believe that, because the worst thing is dogmatism. Uncle Bob convinced young developers to be dogmatic.

I've dealt with code that was a mess with no adherence to rules. I've dealt with teams where everything need to be perfect. The first group shipped products. The second groups had neat looking code bases but had much more trouble shipping. Sometimes it was impossible to get in simple lines of code because it didn't match "the rules".

bc_programming2• 2 years ago

For me, I bought "Clean Code" because it was, at the time at least, quite highly recommended. After being rather confused for a while, I finally stopped reading right around page 141 when I realized that the reason his examples looked awful were because they were.

In that section of the book, he takes a Java port of Donald Knuth's PrintPrimes program, and refactors it. But in doing so, he actually breaks it. He moves state out of local variables and parameters and makes them all static fields, and then refactors the code into long-winded methods that specifically perform side effects or operate on those fields (names like isNotMultipleOfAnyPreviousFactor(), isLeastRelevantMultipleOfNextLargerPrimeFactor()). But the simple act of moving state that would otherwise be part of the stack frame into static fields means he has changed the behaviour of the code - it is no longer thread safe! calling it from different threads will have undefined results because all threads will be operating on the static fields. He demonstrably made the code worse!.

It invalidated the entire book for me at that point. Here's "Uncle Bob" trying to pretend to be some aged, skilled, craftsman hand guiding us young, ignorant whippersnappers into being proper craftsman and not only can't he properly refactor a simple prime number sieve as a demonstration, but he's so blind to awful code that he doesn't even see it in his awful example enough that it gets published in the same book that complained about programmers who don't have "code-sense". Mistakes and "errata" are one thing, but when he makes such a big noise about "do it right the first time" and then has an example where he refactors and literally breaks something, that's another.

Scubabear68• 2 years ago

I started reading the code Martin wrote with his son for the “FitNesse” acceptance tracking framework.

The code was simply God awful. Nearly every method was tagged ad “throws Exception”, no comments, and the famous endless sea of classes with only a few lines of code per method.

The code itself ran with constant exceptions filling up the logs. This was going back over a decade or more when I looked at it.

You can see his lineage of trying to sell consulting services and books all the way back to the comp.object Usenet groups back in the 90s.

Sadly he still commands big fees to speak at various conferences and companies, I was very disappointed when he spoke at Bloomberg many years ago when I worked there.

jrpelkonen• 2 years ago

Interestingly enough, John Ousterhout was a recently on Book Overflow podcast and he says he uses this very refactoring but on reverse to teach good software design. So it’s good for something!

b3orn2• 2 years ago

In my opinion the only good part of that book is the title.

wredue4• 2 years ago

I mean. It’s not like people pushing “side effects” (read: literally any change at all) aren’t also being overtly dogmatic, and writing utterly terrible code.

Uncle bobs book didn’t age well, but neither will the dogmatic stances on immutability and side effects.

pbw9• 2 years ago

As the OP, I was not arguing that Uncle Bob's advice is good; I was arguing that performance is not the reason to reject his advice... unless you are counting nanoseconds, in which case performance is a great reason to reject his advice.

It's a story of two worlds. Casey lives in a world where nanoseconds almost always count. He says OOP is horrible for performance, but he really means it's horrible for performance in that world. But Uncle Bob's book is about a different world: business Java programming from 10+ years ago. There, the overhead of OOP is almost always negligible. One of my main points in the article was just to be aware of the world you are in.

Performance aside, is Uncle Bob's advice good or bad? I think it's a mixed bag. His four main books total 1,552 pages. Some of his advice is rooted in the Java programming world from the 1990s and 2000s, but I think other advice (like "use good names") is valid today in many languages. Sorting through all those pages of advice would require a much longer article; I didn't try to do that; I just tried to address Casey's performance claim, since I think he's totally wrong (in many cases) even while being totally right in other cases.

Uehreka4• 2 years ago

But performance isn’t the reason to reject his advice: common sense and good taste are more than enough of a reason.

When he wrote Clean Code, Uncle Bob created a monster. Tons of people hold that book up as the Gospel of how to write not just OOP Java code, but all code.

Now is Uncle Bob really to blame for what other people do with the ideas in his book? Absolutely yes. All throughout he writes in a super authoritative tone, snarks at people who disagree with him, and asserts that his 40 years of software engineering experience mean his opinions must be right and that he doesn’t have to explain why.

The reaction to his writing is a product of the way he wrote it, and the reaction sucks. In workplace after workplace I’ve had to push back against people trying to sully nice readable code by blindly and stubbornly applying his principles.

It’s an endless struggle, one that would be helped if, like Merlin Mann (creator of Inbox Zero) he looked at what was happening and disavowed his creation and spent years working to correct the public’s misconceptions. But Uncle Bob doesn’t want to do that, so here we are.

pbw9• 2 years ago

I’ll add that “use good names” is good advice. But “use the names Robert Martin prefers” may or may not be good advice.

bishop_mortimer2• 2 years ago

In fact, if Uncle Bob really doesn't want 4-line functions, and wants moderation, he should write a better book. Whatever he claims to mean, everyone sure seems to think that's what his book says.

I personally found it to be one of the most needlessly dogmatic things I've read.

wredue4• 2 years ago

It is economically better for most organizations to conserve programmer cycles than computer cycles.

Yeah nah. At the rate that programs are getting worse, there’s simply no way that this is remotely true now, especially with cloud costs growing quite rapidly.

seadan836• 2 years ago

So like, Clean Code really does say you should write four line functions, and does not put caveats on that statement

This is false. I tried to look this up a few weeks ago, there is no number. The book says (close paraphrase) "functions should be short, and then they should be even shorter than that". It also says, "a function should be only so long that it expresses a single cohesive idea"

There is lot of nuance and wiggle room there, and those are not absolutist statements. Reasonable people can disagree whether small talk length functions are good or not, but the characterization of an absolute line limit is false.

apocolyps6• 2 years ago

I suspect that number comes from this quote a little further down

Every function in this program was just two, or three, or four lines long. Each was transparently obvious. Each told a story. And each led you to the next in a compelling order. That’s how short your functions should be!

tester756• 2 years ago

The most important thing when evaluating things you need to know is: context matters

Principles arent universal across technologies

Hell, principles arent even universal across software kind (e.g goto arent used in C# web dev, but std lib? yes)

agumonkey• 2 years ago

And across teams, business.

Yasuraka2• 2 years ago

The context in this case being that Robert "Uncle Bob" Martin is a charlatan and an impostor.

CrimsonRain• 2 years ago

this comment says more about you than him :)

DonaldPShimoda• 2 years ago

Personally, I'm a fan of when he has argued with academics on Twitter about things that he is actually ill-equipped to discuss, but he refuses to budge because their (factually correct) statements don't align with his limited worldview. Really made me want to get his books for sure.

throwway120385• 2 years ago

The other cool thing about an OOP approach to this problem is that you can hide your optimized LUT behind the OOP if you're careful about the design of it. This lets you have your cake and eat it too. Your users who might be more comfortable with an OOP approach get a way to declare the kinds of shapes they're interested in and the number of shapes they want to work with. Then you can take responsibility for building a LUT that meets their needs and give them the supporting optimizations they need to be successful.

pbw9• 2 years ago

This is a great point and very true.

icholy4• 2 years ago

If anyone wants to read the antithesis of Clean Code, check out "A philosophy of software design"

maleldil• 2 years ago

Amazing book. My favourite parts are the framing of fighting complexity as the main goal of design (strategic vs tactical thinking) and the idea of "deep modules".

dongecko• 2 years ago

I simply love this book!

amai• 2 years ago

tldr;

Premature optimization is the root of all evil. (Donald Knuth)

p0w3n3d• 2 years ago

I think a programmer can set badly any good pattern. We have onion pattern in our code and I get sick every time I enter it. All's great but it implements a graph of state changes navigating which resembles debugging a regexp, also all the ctrl+click navigation is broken because there's one general method for each message root type

Beyond Clean Code

Related Stories