Stop Recommending Clean Code

Recorded live on twitch, GET IN

One of the best ways i can support you all is with a free access to education and paid for bonus features where i directly help write courses for! Please use my code to become a backend dev (or improve your skills)!

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

[drno]

George Orwell wrote an essay where he gave rules for clean English. The first five were simple guidelines. The sixth was "Break any of these rules sooner than say anything outright barbarous." That last one is missing from Clean Code.

[steveg]

I write functions of two basic types. Most of them (the great majority) are relatively small and perform only a few (or one) specific operations. But I also write what I think of as "master" functions that can be quite lengthy, and which perform a series of oprations, which are using the smaller functions. I've done it this way for 40 years and it has served me well.

[atrus]

I’ve always hated advice like a function should do “one thing”. A function ALWAYS does “one thing.” A that thing can be broken down into other single things, but that is always the case. If it can’t be broken down anymore, it’s pretty much useless. Encapsulating multiple “things” is the point of functions.

[CamembertDave]

I feel like the point where clean code goes from being a positive to a negative is the point at which you start thinking of it as a set of rules which must be adhered to instead of just a sniff-test. If it looks messy, it needs cleaning; if it looks clean, it is clean.

[leakyabstraction]

One of the things we realized is that functions with procedural code of 100-200 lines is not that bad. It can be read linearly in a highly intuitive way, as long as it's well-structured. Yes, you can extract the chunks into small functions, but that often provides little benefit, at the cost of creating more indirections to follow, with the added risk that the function will be badly named because the developer wasn't able to find the right name for the subconcept. I think one golden rule for abstractions is that you MUST identify an actually good abstraction with an actually good name. In reasonable, non-bizarre scenarios it's always much easier and cheaper to extract/abstract later than to deal with a structure that is build on horribly unintuitive and badly selected concepts.

[wdavid]

I was hugely surprised when I saw that clean code was published in 2008. I thought we knew better by then. A Philosophy of Software Design is a much much better book. My main concern with clean code is what that book terms shallow abstractions. You break down your problem to such a tiny tiny level that the code in each element (whether that's a function or procedure or method or whatever the language you're using calls it, ) becomes super trivial but the sheer number of tiny basically worthless abstractions makes your code insanely complicated and hard to read or change. I remember the first time I heard someone say that a function should be no more than 4 lines of code and I couldn't understand how anyone could possibly think that was a good idea.

[klaudyw]

+1 for the procedural code thing. To an extent it's the embodiment of "The code should read like a narrative".

[dorinsuletea]

In Clean Architecture Uncle Bob had IMO a very insightful take on DRY :
“But there are different kinds of duplication. There is true duplication, in which every change to one instance necessitates the same change to every duplicate of that instance. Then there is false or accidental duplication. If two apparently duplicated sections of code evolve along different paths—if they change at different rates, and for different reasons—then they are not true duplicates. Return to them in a few years, and you’ll find that they are very different from each other.”

[fuscitas]

I once worked in a c++ code base, as old as i am, with extremely long functions and classes. The were single functions with more than 2000 lines of code and more than 100 returns. It was a nightmare to work with it. After this i really see the value of clean code, as long as you are not too dogmatic about it

[vhaangol]

Based on experience, clean code oftentimes leads to unnecessary abstraction and indirection. There are times when it makes sense to apply the techniques for writing "clean code", but applying it to almost every code is insane. It makes me think, "Are we really trying to solve a problem here or are we simply abiding by these rules because we think this is the only right way to write code?"

[jacobleslie]

Function length is easy. Your function should be the correct length. Done.

[sealsharp]

The biggest improvement to the code i write was starting to do unit tests. Because when the tests are annoying to write, it is a sign that there are structural issues.

[leakyabstraction]

7:20 Careful ordering inside source files is still a great advice. The concept is simply to have the actual public interface of your component at the top, and the implementation details below it. Or, generally, ordering it from large concepts to small concepts. It's easy to see how it is totally confusing when you open a file, which has some name that represents a concept, and what you see there first are some crazy abstract stuff which is hard to connect mentally to the function of the file/component... It's just a general sane advice for decreasing the friction of work.

[froggy]

Wait this guy streams during working hours?? What a mad lad

[godDIEmanLIVE]

DRY suffers from the same problems as zealous OOP code. The level of indirection and abstraction is too damn high which tanks readability, the ability to reason about a contiguous piece of code etc. And even accessability to people not familiar with a code base. It's like dungeon in a computer game with a lot of side paths that you eagerly explore just to be disappointed by their length and lack of rewarding discoveries and loot. Very high signal to noise ratio.

[marcusaureliusfanboy]

25:32 I feel this comes from the expectation that unit tests will target the public interfaces.

Refactoring majorly would involve cleaning up the private methods used in these public-interfacing methods and thus strong unit tests can verify the correctness of the public interface after its internals are refactored.

[Kavukamari]

I'm going to start programming WET and DIRTY code and you can't stop me, in fact everyone is required to watch

[TheChillBison]

I still say I found Clean Code to be incredibly helpful, as I think a lot of those "basics" (or even having a discussion about them) aren't taught in school or in online courses. They either focus on the syntax of the language, or on what you're trying to get done, but not on how to code well so that other humans don't want to beat you with their keyboards. Having seen plenty of examples where code was confusing as all get out due to violating these principles, I think the important thing is for teams to have the discussions, review the code, refactor as needed, and just have something to follow rather than everyone code according to their own opinions.

[fabricedugas]

I really enjoy watching your videos! Being still in the beginning of my programming career and trying to learn from books, I often find myself wondering what experience has taught programmers before me since these books came out. You're down to earth and can easily call bullshit. That's very entertaining 😂

[tiagocerqueira]

I think unit tests are helpful in refactoring for one reason: I want them to break so it reminds me of what use cases and code behaviour I need to take into consideration when refactoring.