Stop Recommending Clean Code

Recorded live on twitch, GET IN
/ theprimeagen
I am writing courses for boot.dev/prime
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)!
Article: qntm.org/clean
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact

[@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.

[@monkev1199]

Yeah fundamentally "is this code clean" is always going to be answered with "I'll know it when I see it"

[@ivanjermakov]

Love that analogy. After thousands of hours of looking through the code you can almost always immediately tell what smells and what not.

[@AScribblingTurtle]

"Clean Code" as a concept has the flaw that it tries to encapsulate understandability, readability, and easy maintainability, which are all subjective traits, that not only influence each other but also highly depend on the programmer's coding style. So what is positive and negative depens on who looks at it. In the Video, the only thing, that `private void includeSuiteSetupPage()` adds is the information of "Page", to make clear, that the `include` in the function is including a "Page" You could have easily done that with a comment or by properly naming the freaking module/file that is included. The function makes the line more readable, yes, but harder to understand and maintain because there is now an extra function, that could possibly be used somewhere else, that could have optional parameters, that could change the instance in different ways.

[@jordixboy]

Doesn't work. Everyone has a different understanding of what is clean.

[@zeezor]

I totally agree, the moment you sanctify clean code is when you start veering off from the positive it's meant to bring to your code.

[@klaudyw3]

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

[@jespergustafsson7664]

True!

[@dickheadrecs]

sometimes you just want to read the synopsis

[@publicalias8172]

@@dickheadrecs ... so look at the summary

[@GeneraluStelaru]

@@dickheadrecs True but not on a paragraph level.

[@dickheadrecs]

@@GeneraluStelaru yeah good point. i’m going to make my code editor make the first letter of each paragraph 36pt

[@steveg1961]

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.

[@Slashx92]

I write automations and that's how I make my functions too. If there is a important step in the automation that needs emphasis, or is the representation of a defined business logic (and not just moving data around) that's a separated function, so it can have a name, and be reviewed and maintained by itself. But it will be only called by the main function Once a function called inside the main function calls more functions that are not utilities, it starts to get messy and hard to follow

[@MoguMasso]

I agree. Whether it's OOP or not, code written this way, in most of my cases, lead to clearly written routines which didn't need too much documentations to understand.

[@dupersuper1000]

I tend to agree with this process. As a FP guy, I prefer to think of it as “data queries” -> “data transformations/aggregations” -> “command executions”. Most systems have that basic structure. You have some data, you need to transform that data into something more immediately useful, and then once you have the data you need in the format that you need, you use that data to execute some process that has some effect on the broader system (e.g. writing to the database or displaying a UI component). It’s all effectively a data pipeline where the end of the pipeline is where you “do the thing,” so to speak.

[@explosiver]

That's basically how programs works as a whole. They have a main function that loops and runs everything else.

[@steveg1961]

@@explosiver I often don't do much in main except use it to call into other functions.

[@vhaangol4785]

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?"

[@airman122469]

I like clean code in the abstract sense. But yes, it almost always, in practice, leads to a bunch of abstractions that ultimately do not need to exist. But I can see starting with clean code, then reducing the abstractions to slim it down.

[@khatdubell]

Neither, its called catering to the lowest common denominator. When you let people use their "best judgement", you will frequently be disappointed.

[@Flackon]

Sorry, too milquetoast. just STOP writing clean code

[@orbatos]

Like many similar ideas, treating it as some kind of hard rule is just ridiculous.

[@NoX-512]

​@@orbatosNot at all. Clean Code is a horror show.

[@reinoob]

"Right click -> format code" is clean enough

[@tokiomutex4148]

Use prettier

[@sto3359]

🤔

[@silviogames]

IntelliJ has a "code cleanup" option

[@maxharmony6994]

mouse user detected

[@ChillAutos]

not formatting on save is a code smell kek

[@andrewallbright658]

“Clean code” soon rebrands to “perfect code by perfect coders; you’re an awful programmer if you don’t do all of this and buy all the books.” Lol

[@replikvltyoutube3727]

Article author: Do this, buy this book Also book authors: article author

[@paulojose7568]

You guys can't even write a book and you're here hating the author who probably just wanted to help the industry in 2008 lol

[@crides0]

But it's not even perfect code. It's just perfect code from Martin's perspective

[@khatdubell]

@@crides0 Its not even that. Its imperfect code form Martin's perspective that he is refactoring. The original code seems to come from Ward Cunningham and Rick Mugridge.

[@NoX-512]

​@@paulojose7568No, he just wanted to line his pockets. Clean Code is a shit show.

[@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.

[@FlaggedStar]

Unfortunately, this falls in to the trap of over-engineering your code. Making code testable forces practices like dependency injection and keeping classes/functions small on you. Those aren't necessarily bad things, but it radically changes the structure of your code.

[@ivanjermakov]

Also, tests are useful for those who want to know how the code should be used. If the unit test was difficult to write -- the unit will be difficult to use.

[@recarsion]

I must have never written good code then because I've never found writing unit tests not annoying af lol

[@aoeu256]

@@FlaggedStar you can have dependency injection with methods rather than needing full blown classes which is much shorter imo.

[@FlaggedStar]

@@aoeu256 That's not considered good practice unless you have a damn good reason to do it. Read some Mark Seesman.

[@dorinsuletea1928]

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.”

[@stunningride6073]

Oh DRY is one of the most misunderstood principles in IT industry....

[@GuusBloemsma0]

It is safer to err on the side of DRY than on the side of duplication. If you have this common piece of code that you factor out and now you have to introduce a parameter to introduce a slight change for one invocation vs the other you can easily duplicate the function later and remove all the conditions. Many refactoring tools even automate that. The other way around you will see two similar functions that grow further apart while trying to do the exact same thing. You recognize it by always having to modify both pieces of code, often in separate commits because it is always forgotten. It is going to be very hard to unify them later on.

[@Jabberwockybird]

WET is better than DRY.

[@wdavid3116]

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.

[@theodorealenas3171]

It is pretty crazy, but so are techniques of high level artists and people don't question that as much. I'm trying to learn to write tiny functions, like Martin, and it seems to be a separate skill set to both read and write these. The benefits are other things, like how you can more easily avoid reading code you're not interested in.

[@wdavid3116]

@@theodorealenas3171 I just straight up disagree with that. I think it's an anti-skill and if your code is well organized in properly sized functions (whatever size that ends up being,) that make sense you can more easily find the code you want because there will be a sensible number of abstractions to sort through when you're looking for it.

[@madjesta]

I've seen code that is abstracted to methods of at most 4 lines. I felt it was utter and total baren trash code that would never make sense since it would take too long to read.

[@jimmyjam-vc6rf]

Yeah some software devs try to be some purist holy man that walks in the light of the divine code quality and standards. These people usually have the worst turn around time for actual features and finished products. Most of their focus is delicately building a house of cards and obstracizing anyone they share a code base with that they must repent for their sins are many.

[@davidgreetman3704]

I have never had a problem with changing sth that was tiny. Of course, reading it and wrapping your head around it is stupidly hard. For me, it is not about lines but about how many things that function (or whatever) does. If it is trivial, do not break it down. If even trivial things are useful because you use it many times, then make that small function. But breaking down code because it is too long is useless.

[@andydavies6522]

I had a developer on my team who used to follow clean code to the letter, and produced code that took an obscene amount of time to debug as it jumped around way too much and we couldn't keep the context in our heads. We dumped the entire codebase and re-wrote it from the ground up and was at least 10x more productive and produced fewer defects.

[@blubblurb]

Same experience. In my case, this programmer was in charge to set the coding rules, so we all had to refactor the code to smaller and smaller functions. Way more unreadable and also way harder to debug. Also with all those arbitrary rules we started to think more about how to structure the code then on how to solve the problem.

[@nkazimulojudgement3583]

@@blubblurb damn

[@kecher1]

Obviously, that developer didn't follow it "to the letter", because if he had used TDD properly which is an integral part of Uncle Bob's method, there would be no need to "debug" that code.

[@blubblurb]

@@kecher1 TDD has nothing todo with no need to debug the code. If the code doesnt do what you think it should do your tests can't fix that.

[@stunningride6073]

@@blubblurb If you can't understand what the code is suppossed to be doing based on the tests then your tests are shitty.

[@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.

[@g33xzi11a]

procedural is great if you diligently use guard clauses, are mindful of placement of intermediates, precalcs, and vars, and carefully use conditionals and nesting.

[@Kavukamari]

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

[@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

[@g33xzi11a]

What's worse is getting the long classes but it's still hyper atomized functions.

[@BryonLape]

Yeah, the complainers don't understand the creating context.

[@jacobleslie8056]

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

[@ThePrimeTimeagen]

Love it

[@chriswolf4715]

I do try to keep my functions to the "one screen" size but I don't treat it as an absolute or anything. If it can't fit on one screen, I look for ways to make it more more succinct. If I can find some, great. If not, no harm done.

[@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.

[@bug3937]

Great example. Working in big java codebases, specially legacy apps feels exactly like that. You nailed it.

[@rodrigoserafim8834]

Any zealotry will lead to radical hyperbole, and applying rules as dogma, rather than applying them for the reason they came into being in the first place. But you are being just as much as a zealot if you choose to burn the DRY concept as a whole. Wait until you have your junior developers copy pasting entire classes and changing a couple of lines of code, and you have to debug and maintain that code. You got to separate the wheat from the chaff, then we can discuss the shortcomings of DRY. PS: Coding languages are built for the exact purpose of abstracting away machine code patterns that repeat themselves over and over again.

[@CaptainToadUK]

I'm much more likely to be following DRY than SOLID when I'm coding but not dogmatically. As with anything, if it's overdone, it's less useful and can even be a distraction. The same can be said about having functions and classes copy/pasted all over the place that have the exact same, or nearly the exact same, code in them. It takes judgement and experience to get them right. In my experience, that's usually what's missing from the dogmatic application of one process or another - judgement and experience. One of the problems is that the implementors of these processes often don't stick around long enough to have to do real support of what they've created and so are never faced with the reality of how hard that can be. And so, they carry on with the same practices.

[@williamdrum9899]

​@@rodrigoserafim8834And then you have a whole generation of coders who only know the abstractions and history repeats itself

[@drno87]

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.

[@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.

[@Tony-dp1rl]

In some parallel universe somewhere , there is a reality where OOP never happened ... it rains donuts there.

[@mfpears]

14:40 A better rule is to create an abstraction exactly when you have a clear name for it. Removing the implementation details and replacing it with a simple description actually _improves_ your ability to understand what's going on.

[@Turalcar]

When I don't have an otherwise strong opinion the rule of thumb I use is "does this make code shorter". If adding a function declaration ends up adding lines having the implementation copied verbatim is probably simpler.

[@g3ff01]

Yes. I worked with some developers that had said that they usually create a function when they see a repetition. I've never understood this. No, it's not the only purpose for creating a functions. If avoiding repetitions was the only reason for creating a function/method, they would have no name, just an id.

[@evancombs5159]

@@Turalcar it shouldn't be, "does this make code shorter?" instead it should be, "does this make the code easier to understand?" Shorter is not always better with code (a common misunderstanding within the FP crowd).

[@Turalcar]

@@evancombs5159 Hence "when I don't have an otherwise strong opinion". Out of 2 similarly legible sources I'll pick a shorter one.

[@aaronhauth8880]

One code smell I encounter is when a function is written that says "DoThingAAndAlsoThingB()" Generally that's a code smell and means your function is doing too much. That could certainly be broken down to smaller functions

[@froggy3496]

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

[@datguy4104]

When I began learning to code DRY was by far the most annoying thing that held me back. Tutorials/courses ALWAYS apply DRY in the middle of explaining something which leads to piles of abstraction and refactoring right in the middle of explaining a concept, which makes learning the concept or seeing exactly what's going on very difficult when you barely understand anything as it is.

[@CottidaeSEA]

Their lips become so DRY, they no longer KISS. They don't keep things simple and make things far too abstract, instead violating a different principle.

[@Flackon]

Yeah it's especially egregious in the context of a tutorial because it muddles up the learning experience. Even when writing code yourself for some new problem, it helps immensely to just write it dirty and make it work first, and only when you understand what's involved, refactor it

[@CottidaeSEA]

@@Flackon Not only that, but even when you refactor it, there are few reasons to split the code into so many parts. One of my primary reasons for splitting up code early is unit testing during development, but even that is kind of rare.

[@theodorealenas3171]

It's dumb because Martin says you first write messy code and then clean it. So he disagrees with what the tutorials do there basically

[@taragnor]

I think DRY is really important. I can't count the number of times I've got weird behavior because I have two different code blocks where I do the same thing and only changed one of them, while forgetting about the other one. More often than not, doing copy/pasta code instead of DRY ends up costing me time down the road, despite the former being considerably faster initially.

[@pilotashish]

flip's doing a fantastic job

[@KarlOlofsson]

The golden rule is "Whatever you agree on in your team/project". If it works and everyone understands things it's good enough. Then you can discuss and improve from there. At least seniors and higher as junior devs can't really be expected to take responsibility for things like this, just be eager to learn.

[@etodemerzel2627]

Queue never-ending discussions.

[@RaMz00z]

There's a *lot* of companies that crashes doing this my friend... Agreeing on something doesn't mean it's true...

[@KarlOlofsson]

@@RaMz00z you cant always save them

[@KarlOlofsson]

@@etodemerzel2627 unless you work alone on a hobby project there will of course always be discussions about stuff and discontent people.

[@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.

[@chri5toph_k]

It's a pity you didn't go through the crazy last example of this article. I read Clean Code around three months after I had my first programming job, because a senior dev coworker recommended it to me. I wasnt so critical towards the super small functions, even though I never followed it to such extent. But when I read, how he refactored the Unit Test, I instantly thought, that I would never would do that in such a way

[@JamesSmith-cm7sg]

Months into your first programming job, and you already know better 😅

[@ludovicmanga8241]

​​@@JamesSmith-cm7sghahaa just though the same. Robert C Martin says at the beginning of the book that you may disagree, but respect the fact that these guys have been professional developers for so long, more than 40 years. So it is hard to match 40 years of experience with 3 months lol

[@gristlelollygag]

Is it just me, or number of years does not equate credibility? It's the merit of ideas, not length of time you spent typing code in an office@@ludovicmanga8241

[@sb_dunk]

The big problem is dogma and fundamentalism. Thinking that _this is the right way_ always ends badly. Coding principles are often good when they're treated as guidelines, and they don't always need to be adhered to.

[@CaptainToadUK]

Worse is when the dogmatism insists it is the _only_ way or removes other ways to do things because of the path chosen. Because there's always more than way to skin a cat, except when you're forced into 'the one true path' and you find that your Cat object is incompatible with the IAnimalSkinner service and so you have to spend hours extending it for that one particular case because that is the _only_ way to skin a cat in that codebase...

[@brianviktor8212]

I code since ~8 years in C#. I improved myself all alone over time. I know the patterns that are most readable and workable with. I do not adhere to any rules aside from what I think is right. DRY is something I automatically adopted for example, but I'd make an exception when it's about something that is performance critical (avoid chained method calls). I do not adhere to at least half the programming patterns because I think they are redundant. I would if they turned out to be useful at some places. The factory pattern for example... there is no use-case for what I did and do. I write a lot of universally usable code that has no dependencies, but encapsulates more or less complex logic. I found a pattern in which every .cs file can be copied out and pasted into other projects, and it will run, but the original project could also be compiled into a DLL and referenced, and also both (just in case). For me well written code and well structured project structure is of high importance unlike to my colleagues. I take everything as guidelines and apply practices as I deem best.

[@carlsandsten11]

Worse than dogma is the resistance to experience just because an engineer/developer thinks he knows best but the rest of the team gets slowed down because of it. Met too many people using the word dogma without ever thinking twice what the right architecture for the project should be and why. More than experience with people using the word than actually understanding it fully. Not saying you are. Just saying everyone I met during my decade.

[@sb_dunk]

@@carlsandsten11 I'm a little confused by your comment, what do you think dogma is? You say that you've met people that use the word dogma and then don't think twice about what the right architecture is, you mean they just go with "this one because it's the one we always use"? ...I would say that's dogmatic. I also don't know if I agree with your point about junior devs, if one always told me he/she was right and I was wrong, I'd get annoyed, but junior devs sure as hell can challenge my opinions and ideas, it's never slowed my team down significantly.

[@schwingedeshaehers]

​@@brianviktor8212you know that you can have "function" that are compiled into the code, so that it don't need a function call? (At least in low level languages)

[@fabricedugas1169]

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 😂

[@olafbaeyens8955]

Clean code only works when you wrote it yourself. But fails when you hand it over to another team and you think that the other team that inherited your clean code is stupid because they don't understand it.

[@diyanslavov7401]

even then it dont work

[@theodorealenas3171]

Yes dammit. By the way I do wish one day the average skills will rise and we'll be able to write cleaner code without bothering people.

[@ghosthunter0950]

Really? I mean clean code was originally defined as readable and easy to understand code. So you would have been wrong by definition. But I think people have really shifted this to aesthetically pleasing code instead.

[@theodorealenas3171]

@@ghosthunter0950 it's easy to leave. You went to the wrong function and you quickly realize it's the wrong function. It's not aesthetically pleasing.

[@olafbaeyens8955]

@@ghosthunter0950 It looks nice, it looks readable but that does not mean that the code works as expected. In a lot of cases is obscures bugs because you assume that it is too nice to have a bug in it.

[@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.

[@tiagocerqueira9459]

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.

[@JonMW]

This doesn't need to even be a philosophical debate: code should be whatever it needs to be for it to be as easy as possible to keep working on it.

[@Bliss467]

A method SHOULD mutate or expose the state of the class. If it doesn’t, then why is the function inside the class in the first place!?

[@davidlanda2324]

Because this book was written for langauges such as Java where one can't write a function outside a class. Anyway metod CAN change a state, but that does not mean that you have to mutate an object. You can return a new object. Mutation can be avoided and is must have in multithreaded environment.

[@llIlllIIlIIlllIlllIl]

I'd like to point out that when you ALREADY HAVE mutable state that you have to take care of, it's a good idea to encapsulate it inside a class and expose only certain methods to handle it. In the given example they INTRODUCED state that is TOTALLY UNNECESSARY which only makes surprising dependencies. E.g. calling someMethodB leads to invalid behavior if anotherMethodA is not called. For me this kind of behavior is very hard to see and clean method names aren't going to help you.

[@rogerdinhelm4671]

Because in Java classes also act as kind-of like namespaces in C++, sometimes they are just a named scope of identifiers

[@Brian-ro7st]

Because you can’t write anything outside a class in Java. Your framing main function is in a class. You’d think Sun would’ve realized they were being too rigid the first time they wrote a main function, but no. Same reason every Java code base ends up with abominable util “classes” which are just a collection of methods that don’t fit anywhere else.

[@davidlanda2324]

Always separate IO from logic. My test to prove that my program is well structured is: 1) Is it easy to write tests? 2) Are you able to easily implement a dry run or swap the CLI for the GUI? 3) Can you easily write to the console and at the same time redirect the output to another program (which makes sense only for the CLI)?

[@JanMagnusson72]

This is also my rule of thumb. If you follow this, the code is generally easy to understand, easy to debug, easy to change and modular. It very likely also works. But it is a rule of thumb, not the law.

[@redhawk3385]

I had a teacher in college who took the clean code pill, and I was one of the few who thought it was bs the whole time.

[@wingedpanther73]

I do a lot of mathematical calculations in the code I write, often statistical calculations. So I run into scenarios where it's "Validate you have all the data, if you have all the data, calculate the results of the data, then determine if the results of the data meet conditions." I COULD split that into three chunks of code, but there are a TON of variables that are getting set as part of validating the data, that then get used in calculating the results and/or in validating the conditions. That's a few hundred lines of code, but it does ONE thing, get the data into an overall result. I have other functions that are incredibly short (as little as 2 lines), but I cannot always make them short when the logic is somewhat involved.

[@vd3598]

It is interesting, that Martin explains Single Responsibility Principle not as "module should do only one thing", which almost everybdy speak of. This is separation of concerns. SRP is actually "module should change by same reason". Which is really not the same as the first definition. This means that even if several code blocks looks similar and the first impulse would be to extract this similarity into single external module, but they have eventually different clients, which may require these code parts to evolve differetly, we should leave them separate. So SRP is kinda opposit to DRY and good code is somewhere in between their contradiction.

[@Sammysapphira]

I hate passive speech like the title of this article. "Ok but can we talk about -" "Maybe it's time to stop - "

[@BurgerKingHarkinian]

I agree. It's never fails to make me cringe

[@knd775]

Oh man you’d fucking hate theo, then

[@Gabriel-mf7wh]

The better title would be "Stop recommending Clean Code"

[@prism223]

It sounds like how women try to prompt sincere conversations with their virtue signaling, superficially judgmental fake friends.

[@sburton84]

I knew Uncle Bob could be a bit dogmatic with his rules but I at least thought his code would be alright, but I'm actually shocked how awful those examples are. That first example would be a good example to show someone to demonstrate the meaning of the phrase "spaghetti-code".

[@itellyouforfree7238]

He is not a good programmer. He is not even a programmer, just a preacher. He's an incompetent wannabe going around preaching nonsense to misinformed coders.

[@d-rex7043]

I started getting into a procedural style, under my own steam, when doing a C course in uni... but after making all these beautiful atomic functions, I then had to pass about 5 or 6 of them in as arguments to the function that would utilise them to actually do the intended task and so the argument line would end up longer that the function body! When the coordinator's 'Solution' was released, it would generally be a few chunky functions that would get a whole task done (Parse args...Do the Program... Output/Terminate) and the odd helper, simply for carrying out a sort, or something, by wrapping a library function to suit this particular program. It probably too him less time to code the entire assignment than it too me to figure out how my 'simple' functions were going to interact, on a whiteboard.

[@etodemerzel2627]

Passing 5-6 functions as arguments? Are you sure you were doing procedural programming?

[@chetstriker]

Debugging an issue becomes a nightmare when people create functions inside functions inside functions. It drives me crazy when I see that

[@AntiCookieMonster]

I bet Martin would say about needing to go into debug is a failure of clarity in code, or something like that. Funnily enough there are highly successful devs who when exploring new codebase NEVER start from reading the code instead immediately stepping through it with debugger. What tools you use definitely changes your perspective on what good structure looks like. Another example might be code completion and dependency injection not playing well together.

[@Winnetou17]

Hell yeah! When I have to raise my "max open files" to 100 in my IDE just to be able to have a normal, maybe a bit complex, flow opened and having 5 "Processor.php" files ... yeah, VERY clean, I can't tell which is which, where I started, where I went, so helpful, much productiveness wow!

[@aoeu256]

Instead of debugging you could write tests.

[@aoeu256]

@@AntiCookieMonster For a code base in a dynamic language you could write introspection tools that convert every function into a logging version of a function, and then get your editor to show the logs next to the function when your editing it while the program is still running.

[@chetstriker]

@@aoeu256 I'm talking about when I get hanging somebody else's code that I'm supposed to fix and then you have to figure out what they were doing, and how they organized stuff. Tests are usually written after somebody had it working if they even bothered. It's easy when a function encapsulates an full idea minus the parts that are going to be reused a lot, but it's a nightmare when you're trying to read code where the function just points to 30 other tiny functions with pointless descriptions or hundreds of tiny 2 lines of code functions where you have to jump everywhere to be able to read anything

[@arkandosDE]

I've refactored that code listing to what I would do, mostly by inlining everything - it turns out it is all a single function render() that is not even 30 lines long. It's super straightforward logic, I never indented deeper than single ifs, it fits in a single scroll, and it is painfully obvious that all it does is add some test stuff around the page. The right abstraction is not a class, a method, a GoF concept, but a function.

[@afayes]

I have used the pattern of using very small methods for some time and can shed some light on what I think. One big disadvantage is that understanding the whole implementation is a lot harder. One advantage is that, you can quickly understand how a single function works at the current level of abstraction by reading through the well named method calls. The method implementation reads like natural english rather than code. It is easier to mentally process a single verb or phrase than to read multiple lines of code. This is at the heart of this style of coding. It is about quickly understanding, with little mental processing what the current method does, at the current level of abstraction without caring about the lower levels of details. A class in an OOP language like Java will typically have a few public methods. Using this style of code means that these pubic methods will be small and orchestrate their implementation calling private methods. A developer reading a public method can quickly grasp what it does at a high level without needing to process low level implementation details unless they need to i.e during debugging. Whilst I do find this style of coding elegant it can lead to lots of small methods and also figuring out the whole implementation and what the code is doing from A to Z is a lot harder than if everything was coded in a single method.

[@minastaros]

The truth is probably in the middle. Both have pros and cons. Thinking about rather smaller functions is certainly better than rather larger ones. But making _tiny_ ones only because you can is exactly the evil you described: then they lay side by side in a class _without workflow cohesion_ , which the same code would express if it were together. As you say: quickly grasping the _overall_ functionality by only reading high-level concepts is one aspect. But sometimes you need to track down a feature (or just debug something) from top to bottom in foreign code, and that can get very very tedious with the number of levels. That's what the "as small as possible" advocates oversee: the more functions, the more levels on the call stack, which _increases_ noise on another level. The art is to balance that out: providing a level where the program structure can be understood on a high level, and likewise help those who need to dig deeper by avoiding fragmentation. (You notice that I always look from the reader's side - that's what the future writer-me will be on my own code, and all the others that might review, debug, maintain that code)

[@anewbimproves5622]

I use unit tests for refactoring large methods and functions, usually when I'm handed a codebase with a non-obvious bug and I'm trying to understand it. Basic flow for this is: - find block of code in the function (e.g. large for loop) - use ide to extract the block wholesale to its own function with a descriptive name - write a unit test for the new function - reactor it if necessary - repeat until I understand what the code is doing I agree that in general the "only one nest per function" advice is bad though. I only do this kind of thing with really obtuse code that I need to modify or fix.

[@malcolmhutchison]

The old rule for a function being too long was if it didn't fit in a screen (back when 32 rows was common) . That was a soft limit. Tne hard limit was 2 screens (so you could page up and page down to swap between the 2 halves). If you function was longer than that the there were clearly bits that could be extracted into their own named bits of code whic would then make the original function easier to follow

[@mfpears]

13:00 Totally agree. I've always hated that example. It requires so much trust in the names of the functions, and even then you can't be 100% sure _how_ they're doing why they say they're doing.

[@BiHMaverick]

I love how flip doesn't listen 90% of the time.

[@flipmediaprod]

it ain’t much but it’s honest work

[@MrShnaiderTV]

9:17 - It's so funny when he says "I find all of this incorrect" and then switches to his code, which follows exactly the rules from the highlighted paragraph. The difference between the thinking of Martin and the author of the article with the author of the video is that they believe that the class is read all at once. In reality, while reading, you do not fall below one or two redirects, because you want to understand "what" the method does, and not "how" it does it in all the details. Such a division into functions allows the programmer who reads the code not to waste time on pieces that he does not need and it is polite on the part of the author of the code to give him/her the opportunity to stop at the level of abstraction at which he/she needs it.

[@sovahc]

There are goals in programming: compact code, fast code, easy-to-understand code, reliable code. You have to balance it out. When you look at your code and say: I can't improve this according to my goals - you have the best code. That's all.

[@espenskeys]

The functions in the example are not there to prevent repetition, they are there to hide the implementation of the different concepts behind an english word description of what is happening. The idea is that you do not need to know the details about how you include the setup page, you just need to know that at that point, that portion is being handled. The whole point of clean code is to write for the next developer who has to work on the code you wrote. The private, only used once private functions will be inlined by the compiler, there will not be jumps, calls or returns made.

[@SianaGearz]

But then you have the situation that the English description is faulty, it does not encompas exactly what the function does. It's worse than a comment. And you have broken up flow instead of through flow, so when the code does something that isn't quite what you expect it to, it takes too much extra effort to understand.

[@CottidaeSEA]

Clean code in my book is just ensuring things are properly named, the control flow is easy to read and swapping parts out if necessary is not a massive headache. I don't believe that's something which should change. Basically, overengineered solutions are not clean code and I will die defending that hill.

[@ThePrimeTimeagen]

I get you have your own definition, but that's not the definition of clean code. Clean. Code is a methodology.

[@CottidaeSEA]

​@@ThePrimeTimeagen I am very aware of this. The article itself also mentions it in the beginning, that we all have our own definitions of what "good code" or "clean code" is. However, even if looking at the clean code principles, what I've said falls in line with those. The issue with what the examples given in the article is that they do not follow the KISS principle (keep it simple, stupid) that is also a clean code principle, they actively contradict the clean code principles. If you add loads of layers of abstraction through extracting functionality that doesn't need to be extracted, you're not keeping things simple. So I'd say I'm very much in line with this methodology.

[@NoX-512]

​@@CottidaeSEAThat is Clean Code in a nutshell. Some tried and tested rules of thumb, combined with rules that are outright ridiculous. You can't honestly tell me you are ok with that mess being recommended in CS classes.

[@CottidaeSEA]

@@NoX-512 Once you take anything too far, it stops being useful. These people take the naming and small function stuff to the extreme, which is not useful at all. As the article also explains, the given code examples also go against the very principles the one who wrote the examples promotes. That's how bad the examples are. This garbage is just bad code that violates the very principles it is supposed to promote just for the sake of keeping functions small.

[@NoX-512]

@@CottidaeSEA You are wrong about that. The examples are in line with Clean Code rules. Clean Code is taught in CS classes as rules to follow. I'm sure you would agree we shouldn't teach students bad habits, since bad habits can be very hard to get rid of.

[@Paralellex]

The problem I have with dogmatic DRY is that sometimes the same (or nearly the same) code in two different places is two different conceptual ideas that happen to have a similar implementation, for now

[@DePhoegonIsle]

Watching this made me feel 1000x better about my java code.. and I wish I could say I was better. I've had to learn to do it within the bounds of Java MC modding (forge/fabric) and I often end up with .. just larger 50+ line functions because their setting the entirity of a variable set into memory or handling it into a save file or comparing it one by one. This. I know I've done my level best to keep my classes small but some things just can't be helped as they get complex, but honestly I always found that these .... Well I'm going to abstract and clean one line of code into ... 5-10+ because it can't be tracked, and it's not like it's simplifying the actual function/implementation of it, it is only complicated it making more prone to user mistakes. I split my what 46~ global (to my project) variables across 3 different enums when I could have had it it one enum and it'd been technically smaller, but more complex and prone to user error in calling an value of an enum. I know alot of these are about that kind of talk but ... this honestly harms new users greatly as when new users (from experience myself) attempt to clean code.. they end up with .... a logic structure that takes 10x longer or more to understand and that's even if you understand the language & project structure being used. They end up with screenshots where it becomes far harder to identify the problem or have the IDE help you by passing the correct variable or highlighting the usage of it, or being able to follow it, and makes it easier to accidently set up a loop or overlook something because it's all separated, and the new user isn't given that 'Oh, I'm missing that entire else tree of logic,

[@DinnerIsDelayed]

Flip in fact, did not cut it out lmao

[@offilawNoone]

I'm new to coding, since this is my third career) And it always seemed to me that I'm not a very good programmer, although I like it. Like it more than anything else I've ever done. But it turns out that I independently developed exactly the same approach to clean code as you have. It's cool to realize that good programmers think the same as me.

[@InfinityLabsTechTV]

The only "good" programmer is the one who gets the job done with acceptable tolerances, with bonus points for getting it done fast. Limits are OK as long as you're aware of them and not blindly jailing yourself into a paradigm.

[@anonimowelwiatko4455]

I got some experience and started like a bozo too, first writing whole code in int main, then moving to big functions, finally classes/structures and setting up my personal style of coding that would really make me feel like I am writing a good, clean code not because I am forced to but because in my opinion, this is what works for me the best, is clear and well put together. I also went through extremally short episode of writing one or two line functions but it just doesn't sit with me. If function declaration and body will be longer than this statement, what's the point? If this functionality is doing two things but they can't be separated or it would require passing too many arguments to make it appealing but functionality itself won't be separately used, should I split this function? Asking questions and answering them I found out that it's the best to be between. Just hit right balance and make your code read like a good set of instructions, recipe or short but well put, logically connected story.

[@dudaseifert]

When i joined my current company, my direct supervisor was very into clean code. he'd mark my pr's for changes and i'd abide like a good little junior dev. then i had to upgrade the projects rails version(if you've ever done this, specially from 4.2 to 5.0 you know how hard that can be) and i had to refactor code from basically every programmer that ever touched that project. his were one of if not THE hardest to refactor, because it would take a long time to even understand what it was that the code did. nowadays i think we have much better standards in place than just clean code

[@zactron1997]

My rule of thumb is a function/method/class/variable/etc should exist in such a way that the intended maintainer can fully understand what it does and why. If my code needs to be maintained by less experienced devs, then I'll put more effort into atomizing concepts to move more of the code base into higher level abstractions. If my team is more experienced, then abstractions can be a little more complex. Overall, I really like the style you use and propose.

[@g3ff01]

Thank you!

[@istovall2624]

I like the scene in saving private ryan where they assault the machine gun post and the sgt is saying how bout this how bout that, and the cpt says "how but you shut up"

[@robindeboer7568]

Heres my thing about the 80 column limit. A function declaration with 3 arguments in it goes to 120 if the names are slightly long. And i dont like splitting those over multple lines if i can help it, especially when im implementing or overriding another interface/class (Its a personal preference though. Although when it gets too long I split it so theres only 1 argument per line) So I have 130 limit and instead, when I start to reach the width of the declaration, which wont be the full width of the window unless the names are really long, I know its too much. At 80 columns, i feel like it just enforces variable names that are too short to be descriptive, and you start doing newlines for every argument for every function call with multiple arguments even if you only indented twice, rather than actually limiting your indentation. basically, function definitions annoy the crap out of me with 80 character limit, but i think 80 is a pretty good rule of thumb for the body of the functions and i only go over 90 if the names are long.

[@asdqwe4427]

Dry is only good when you are 100% sure that the code does not have to change independently of each other

[@jgnmoose]

I worked in a “clean code” shop. The end result was you are writing very specific code that would only work in that code base.

[@zxuiji]

14:54, While I agree they went too far with their refactor I also think waiting until you've duplicated even once can be a bad thing, for example recently I was programming a custom preprocessor to run BEFORE a normal preprocessor, the loop for mapping characters to code sections grew fairly large and it became hard to keep in context what was being done where, so I created a couple of inline functions above the main function and shifted the relevant code there, with that I was more easily able to see what was being done where since I only needed to call one of them in a if statement and the other afterwards to add the actual section of code. A few re-thinks later and I had a brutally simple preprocessor that will be able to support loop, templates, types and the usual macros :) Still working on the library that will support it though as the code will be part of the library rather than the app itself, the reason for that is so I can use it on shader code also.

[@Jason-xw2md]

I think that living fast and dying hard by any rule or guideline is just limiting yourself. Imo one should take the pragmatic approach, if it makes sense to abstract something right away then do it, if it doesn't, then don't. Everyone wants to apply things unilaterally and treat these guidelines like silver bullets instead of just using them as a tool

[@TurtleKwitty]

That's the differenc betwen "This code is becoming overly complex, what are the functional units I can extract out to make it easier to reason about" vs th clean code "this if block has two statements thy must be made into a fun tion that als ocals a function that calls another function to set a single class variable". There's logical places to split up code but they never lead to anything near what "Clean Code" dictates (aka clean code =/= "Clean Code" in the slightest)

[@Winnetou17]

I think the original idea was that if the only reason to refactor is because you want to avoid duplication THEN you should think that it should be used in 3 places and only then abstract it. Not that all abstractions should come from using duplications.

[@SeanJMay]

So, here are some missing things, that both Pimeagen and the author missed: 0. Problem: "I have a bunch of small functions, and then I have a big function that's a mess of all of the other ones" Answer: This isn't really something that's a problem; these things can be broken down into phases. The lower the level of the library, the tighter the function should be, and the less stateful it should be. There are bootstrapping phases, and there are compositing phases in architecture; regardless of whether you're talking about FP or OO or just Imperative Proc. In FP it's the I/O code, and everything else is stateless. In an OO server, it might be a "Controller", in proc, it's whatever is close to Main; the closer to the start of the callstack, the more messy and mutative you can be, as you tie the pieces together. But you don't want your math / i/o / string / date / etc libraries to be internally stateful, or you're stuck on one thread, and in one single function invocation at a time, period. 1. Problem: "I pass in booleans when I shouldn't and something is wrong, and I don't know what" Answer: Bob actually talks about this, and the author didn't catch it? And it's good advice. A function might have a bunch of control structures to figure out what *should* be done, but then call out to another function to *do* them. That generally gets rid of the boolean passing, because the outer function decides what to do, and the correctly chosen inner function does them. 2. Problem: "How can Bob say that a function should have 0 arguments, but also no side-effects" Answer: the book is about Java, not about any other language. His point was that an object instance should return a *new* object instance, rather than mutating the old, when possible. So technically, the function has access to all internal/external class properties of that instance... it just shouldn't mutate them, if performance considerations allow for it. For procedural languages and functional languages, this is just treating data as immutable (whether or not it is actually immutable); as for the number of arguments, it goes from 0 to 1, if there is no `this`. Simple as that. His point was "ideally, it should take 1 struct and return a new value of some kind". It's just that in Java, the struct is `this`. 3. Problem: "Bob wants DRY everywhere" Answer: actually, Bob suggests pretty hard against DRY. Point being: if functions are tiny, and they do 1 thing, you can use them to do 1 thing on a bunch of stuff. Think `.map`; if it were a function called on an iterable, or a stream, or whatever, rather than a method, you could use it on a lot of things, in a lot of cases. That's his version of "DRY". In FP, that's called "Function Composition". Primagen called it "Legos". 100% same deal. He specifically warns against the typical DRY: that being big, gross kitchen-sink abstractions that need all kinds of special-case behaviors ... he already warned about how gross DRY can be when he suggested the Interface Segregation Principle and the Liskov Substitution Principle; he doesn't go back on it, here. There are others, but ehh. This is enough. I really think this author missed the crux of the book, entirely. Not to say all of it's gold... and a bunch of it isn't relevant, unless you're a Java / C# dev, specifically, and only using Java patterns that predate JDK 1.8... but a lot of the points in the book are either being intentionally misconstrued, or just obliviously missed (I presume due to lack of historical context of where the industry actually was, and what Bob is even talking about, and what problems the book was solving for). Now, none of this is to say that I'm 100% in Bob's camp. There's a bunch of good advice in the book; advice, not dogma; please don't start a religion of Bob (too late, I know). Personally, I hate the `IncludeX(); IncludeY()` nonsense. That feels like PHP to me. It also feels profoundly stateful (given they are not returns, but outputs). And thus, I find them antithetical to his point about functions. I wouldn't have a problem, however, if they were returns building properties of an object: `header = getHeader()` et cetera. When it's just i/o and no hidden state, there's no extra context to load, and no gotchas, it just does what's on the tin. That's not to say that all code can be that simple, but it is worth trying for, rather than having stateful code buried way down the callstack, and realizing that you can't have more than one network connection or thread or concurrent process at a time, because you start giving data to the wrong user.

[@Rockem1234]

Since most of the code we see every day is really crappy, this is a must read for every developer

[@MrOnePieceRuffy]

Abstraction itself is already the Compilers Nightmare, because it can't predict sh*t from it, but to abstract every few lines of code into interpreted functions (a compiler would optimize them away anyways) would be the Processors Nightmare aswell, so I can't take his advice other than "create the pure Hell for your Computers" and well, no need on that, thanks. If an C-Dev who creates branchless code on a daily bases, would give me "clean code" advices, I would start to listen,. WithJava I just start laughting.

[@banatibor83]

Wrong approach I think. The code should be optimized for humans to read, then the compiler or preprocessor can optimize it for the machine as much as it likes, IDGAF, just do not want to read code which was optimized for the compiler.

[@MrOnePieceRuffy]

But, that's my whole point on it... If you write branchless C-Code in embedded Systems on a daily basis you know THAT and WHY your code is ugly. If such a person would have advices how to write clean code, I would want to hear, what he have to say about it

[@MrMudbill]

Doesn't all code start out as procedural code, at least in part? The very idea of the main function is just that, no? So you can have 99% OOP or 99% functional, but it always starts out with that very first procedural entry point.

[@Mitch_Crane]

If I think about this too much I find myself in a philosophical crisis regarding the creation of the universe

[@adam7802]

I was told early on the focus on readability over doing anything clever, but then I didn't do a degree. In my current project at work there is a ton of stuff abstracted to extremes and it drives me crazy, especially when debugging.

[@jager0724]

This is how I write clean code: 1. As few curly braces as possible - luckily one-liners don't require braces, so if you have a one-liner if/while/for statement, no braces needed. Arrow functions can also sometimes be reduced to a single line with no need for the return keyword 2. Functions are verbs, non-booleans are nouns, booleans are verb in 3rd person Sg. + description (e.g. hasItems, isAdult, didWin etc) 3. Declarative with state 4. Extractions are labelled deliberately such as utils & constants dir/file 5. Pick one date type (Date or timestamp) and stick with it

[@pchasco]

I stopped reading the book after I read his advice on functions. And I am very glad I did not read this early in my programming career.

[@airman122469]

Yeah, the advice on functions is garbage. The architecture guidelines aren’t horrible though.

[@ebn__]

17:45 You are not crazy sir, that's the only reason for OOP to exist.

[@erickmoya1401]

Wasnt "Clean" done in a world of newbie programmers doing OOP?

[@robertluong3024]

Thanks Prime, I loved the point about unit testing. It's important to go outside in for tests.

[@ohmyv3gatron]

I’m glad he said “Lego” because that’s exactly what I think of especially when using lisp. In lisp it’s nice because you can evaluate your small form right there and guarantee/see that that one little piece works right then and there.

[@KonradGM]

I never understood even the distinguishing between OOP and PROCEDURAL (to some extend). Yes oop has Abstractions, inheritance etc, but in the end the code is still called in some predefined sequences. So a lot of the time, it's just calling A.function() instead of function() itself

[@MichaelPohoreski]

You are essentially correct. Too many programmers don't understand you can write OOP in C or even Assembly Language (the game Robotron: 2084 written in 1982 did this!) There is a reason the original C++ compiler, CFront, would translate C++ into C. The difference is more about providing a *standard implementation to an API* automatically by the compiler. e.g. C++ the compiler automatically pass a hidden "this" pointer. In C you can get the exact same effect by manually passing a "self" pointer. The C++ compiler automatically generate virtual function slots. You can have virtual functions in C you just need to manually do it. C++: Bitmap.Draw( int x, int y ); C: Bitmap_Draw( Bitmap *self, int x, int y); You can tell Dennis Ritchie didn't understand the importance of providing an standard API with fseek() and fread() having the argument FILE appear in a different order. :-/ int fseek(FILE *stream, long int offset, int whence); size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream) fread() should of had the FILE be the first argument since you are doing something WITH a FILE object.

[@etodemerzel2627]

I see OOP as a toolset full of very advanced tools. You can use some of these tools when you need. Unfortunately, many of the modern programmers have never learned anything else, so they tend to overuse the advanced tools as if they were just primitive building blocks.

[@roboterbasteln]

C++ classes just provide the structure for stuff that belongs together and preserve object state. In C you'd have a struct (the data; POD) and some free functions to operate on the struct. In C++ you can put the data and those methods into one class. That makes it clear what belongs together and works together. Also, you can design a class in a way that it will always keep its invariants, i.e. it never produces an object in an invalid state. That's impossible to achieve with structs in C, since all fields are publicly accessible. So, most important aspect of OOP for me is encapsulation, not abstraction and certainly not inheritance. IMHO, inheritance is a much overused concept and FCoI (favor composition over inheritance) is the way to go. You ask, how is OOP different to procedural. Let me ask back, what is the difference between procedural and imperative? There is no difference. Procedural is imperative and OOP is procedural. They are contained in each other.

[@digitalnorth]

Unrealistic Code beauty standards in 2023 ? Nahhh

[@jesustyronechrist2330]

People think differently. They connect stuff in their brains in different ways. To me, this guy thinks in a very particular way which is "lego blocks": Small, varied little blocks that can be stacked and connected. But to me: Legos are too damn small. I would at most go to toyblocks within toy boxes. Because I don't think anyone organizes their legos: We just throw them in the same box of chaos.

[@climatechangedoesntbargain9140]

The alternative to DRY is worse... Having to change code thats duplicated somewhere else, and you don't remember where or even know anymore that it is somewhere else (the norm when working with multiple people). The result is you change functionality only in one place, fix a bug only in one place. Now image you have duplicated code that again contains duplicated code -> problem gets twice as big. If you find that you dryed something wrongly, it's easy to tear it apart again (and this will happen less with time, because you will learn if something is just accidental duplication or not). The other way is less trivial. Repeating yourself three times: You repeat something -> have I already repeated this before? You need to search the code base if you repeated something AND you rely on it hasn't been refactored locally (e.g. Better variable name) and that you need to search a small enough subset of the code you are duplicating, because you don't know how muchbof the code may have already been duplicated.

[@Inf1e]

well, no if it's a common method which can be factored out -- it will be factored out if it's not -- probably it's a different thing, and you shouldn't group that in the first place

[@khatdubell]

@@Inf1e such an idealistic view. Take any significantly large codebase and you find find chunks of repeated code. I’ve personally been bitten by this bug enough times that before I change something I do a search on the codebase for identical code. The problem with that is that it might be identical, but not 100% identical. So a place that needs updating doesn’t get it. If you find yourself copying a block of code, you should ask yourself if you aren’t better off making it reusable. If the answer is no, you should probably notate that it’s a copy of similar code

[@darylphuah]

​@@Inf1e my team recently spent about 6 weeks refactoring some code which had chunks copy pasted at least 3 times in different areas, I think the record was same chunk 9 times in different files. it was a bloody mess to untangle. This is what happens when you don't follow the DRY principle.

[@Yay295]

@@darylphuah We had a collection of 16 applications all using the same common code, and all of it was duplicated. Except sometimes it had been changed to fix a problem in one of the applications, but not the others. It took me a few months to untangle that, making sure to keep all of the bug fixes from each of the applications, without breaking one of the other applications by adding that fix.

[@marcusrehn6915]

It makes sense to have a few set ways to communicate with another service, but I see so many cases where module X is used by A, B and C, in the name of DRY. Then something changes in B, and then someone adds some more parameters and if statements to X. Let this repeat for a while and you got yourself a ball of mud. In so many cases, copy pasta makes more sense.

[@PbPomper]

I think most ideas and concepts from Clean Code are good general advice. Its mostly common sense. You still also need common sense to know where and when to apply them and when to "break these rules".

[@khatdubell]

This is true for programming in general. If you can recognize the benefits of advise and when to apply and it when not to apply it, regardless of your title you’ll always be a junior developer.

[@theodorealenas3171]

Yes, Martin has a few demonstrations of himself coding for warm up and stuff, and he's just a good programmer who says philosophies. But I wouldn't call the concepts common sense, they're eye opening to me

[@g3ff01]

It's common sense, because you already know this. For example washing hands after toilet or after an autopsy is common sense, but it was not before 19th century. Doctors even laughed at Ignác Semmelweis because of it.

[@Martinit0]

"Put the ass back in class!"😂

[@ccl1195]

Hey, thank you, I stumbled upon this randomly not knowing about your channel. I do amateur software design work. I think I'm doing pretty well with it lately, despite not being formally educated on the subject. While not knowing all the terms you are using, I can see and feel from the video what you are talking about. I've always loved software, but for years there's been this intuitive feeling that's kept me away from it. I now know, it was this stuff!! I saw crap like this all over the internet. Advice from people on forums when I needed help, that just made me want to bash my head into my desk. Smug advices that made me feel like people were light years beyond me in terms of understanding simple languages. Tons of indecipherable github pages with no explanation that made me feel like they were written by magical interdimensional space wizards. Nope. All along, it was just annoying, bad code, and I intuitively knew that it was, even being a neophyte with only piecemeal scraps of formal experience coding. It's really useful to now know that this tome existed, and was disseminated widely as good advice in the academic and formal worlds of software. The older I get, the more I find there are nearly always phenomenological causes for effects in the material world, even if they are often somewhat hidden. Thank you for your video, this is really useful education for me. Much appreciated.

[@Yuri-bt4wl]

Function calls take time (those precious little microseconds add up) and stack space. Too short functions means too many function calls.

[@Glinkis]

A good compiler will automatically inline function calls.

[@spatialfree]

Clear Code > Clean Code

[@saunved]

I have found unit tests to be incredibly useful during refactors. They offer solid proof that your code works as intended and can help avoid obvious mistakes by forcing you to think about potential edge cases better. As long as you don't overdo it, they're a nifty tool. Whenever I'm refactoring a function (read: changing HOW it does something and not WHAT it is doing), I add unit tests before just to ensure that the overall input->output is stable. It acts as concrete proof for the refactor. If someone's refactor is changing the behaviour of a function - then it's not a refactor. It's basically a feature or patch and those are only truly verifiable via integration tests.

[@DevRel1]

I so love his clips being interrupted by "Welcome to Cosco", it's the only reason I really watch the channel.

[@Glazer209]

I don’t think it’s procedural vs functional, it’s procedural vs declarative. Any worthwhile high level code is going to be declarative, because it allows the procedural implementation to optimize because it’s abstracted. SQL is a great example of declarative, because you don’t tell the system “how” to get the data. You just declare the data that you want and the DB will determine how best to meet that.

[@BosonCollider]

I feel that a big cause of this is that many languages in 2008 did not let you define nested functions. Many classes that were written could be replaced with a big function, that defines some variables and some inner functions that are helpers or which are procedures that do work on those variables, but never escape the function body.

[@NoX-512]

That’s not a big cause of it.

[@marcs9451]

just include a nested scope, C has that, so does C++, Java, Rust, Go, D, Odin, Zig and pretty much any real language

[@vhaangol4785]

That's just another way of producing unnecessary abstraction. Many classes can be written in a simple, procedural manner. You don't have to create these functions that return a function (e.g. in JS where it produces a lot of memory). It's just that people often become obsessed with these patterns or principles that they apply it to almost EVERY code without understanding when they are supposed to be used. In the pursuit of mastering these programming techniques, we sometimes forget that code can be written in a simpler manner.

[@BosonCollider]

@@vhaangol4785 No no no, I didn't mean you return them. I just meant you declare the functions and use them only there. Since sometimes you do want the same block of code to be applied several times in the same function, but it will still not ever escape the scope of that function

[@ivanjermakov]

Note that in most languages nested function defenitions will cause performance overhead

[@avi7278]

I knew a lead dev who had a rule that your function can't be longer than 10 lines. It was great, that guy was a blast.

[@capivaraalien1466]

About the function discussion, It's probably more effective trying to think to break functions not in how long it is, but about the properties of the function. Is the function extensible? Is the function testable? Is the function isolating a problem? Is the function easily readable? I think the decision if a function is long enough should come from the concept you are trying to implement, from it's purpose, or any other property related to it's use.

[@khatdubell]

18:34 This guy either actually just skipped ahead to the listing and didn't read the book, or he's being purposefully disingenuous here. This is what the book says about that code. _"the method call render(true) is just plain confusing to a poor reader. Mousing over the call and seeing render(boolean isSuite) helps a little, but not that much."_ The context of this code is BAD code that he is refactoring in the book. Its not his ideal, written from scratch, "this is how you should architect things" code example. More to the point *Its not even his code* Its publicly available java code HE IS REFACTORING.

[@ShawazImam]

LOL

[@poseiso]

I used to code like that... then i worked on this moderately size project and made the functions *atomic* and holy shit it was hell and yes there was a lot of unnecessary indirection and abstraction thankfully i've learned now

[@zsytssk5176]

In my opnion: The best way to code is not Object Orientation or Function Orientation, is Data Orientation, Data is the most important thing in code.

[@thegrumpydeveloper]

That late meeting exit at the end is priceless. Have had that way more times than I care to admit. 😂 26:44

[@khatdubell]

Tell me you've never worked on a codebase with a single, thousand lined function without telling me you've never worked on a codebase with a thousand line function. The problem with saying "be reasonable" instead of following dogmatic rules is that everyone has a different version of what is and isn't reasonable. The villain in the story never thinks they are the bad guy. When you give someone a rule to follow, they don't have to think about it.

[@HrHaakon]

That's a great argument for code reviews, standards, having the tough conversations and agreeing and sticking to conventions. Which is the hard part of being tech lead. But that's your job.

[@NoX-512]

If the rule is good, great. If the rule is garbage, you are in for a shit show.

[@elimgarak3597]

Clean code and, in general, most software architectural concepts, are pre-science, which is sad. With this I mean there is absolutely zero reproducible experimental evidence backing up their claim that clean code or whatever other architectural advice they give leads to goal X (be it maintainability, lower dev time, etc.) with higher probability than other ways of doing things. In other words, it is almost speculative philosophy (which is fine to do in domains where you cannot do better than that, but this isn't the case so it is absolute BS). Instead of wasting time with platonic metaphysics we could be trying to make these hypotheses testable, and submit them to rigorous experiments. We could learn a thing or two.

[@jl6723]

But are they even testable to encompass why people want clean code? I think that we will find such tests to be very uncertain and as such not that useful simply because when we describe something as maintainability, we may well describe 20-30 different types of maintenance actions, which we have to order in important for a calculation of a score. All testing of Clean Code will likely rely on non-scientific decisions as fundamental axioms. The results will vary wildly. In such a case, it is more useful to make it a conversation of style about advantages and disadvantages that are speculative, because at least then people are encouraged to have practical experience with the subject matter to find out what works where.

[@SororiaAltria]

People nowadays are so desperate to apply "scientific" approaches, so desperate for the "objectivity" that it's really unsettling Really shows how traumatizing the death of God actually is

[@iammarkasmith]

​@Airo Signi, Karna Duvi ha. My mind went there as well.

[@elimgarak3597]

@@SororiaAltria by all means, practice whatever subjective pre-scientific approach you want to. Leave God and all of the other "absolutes" stay dead if you wish to. Just don't present it as something objective and impose it as an industry standard.

[@iammarkasmith]

@@elimgarak3597 Objective vs subjective cannot be applied to all things. And that is his point. As an example, objectively, it would be better to kill 10k children to save 100k others. But should I present you with that choice, are you going to make the decision scientifically, putting 10k kids to death because its objectively better in the name of science? Too many people think science is the new God of reality, but 1. Its not always clear that science is actually objective) and 2. When it comes to questions of "should you ought to" science often comes up short. 3. Lastly, the scientific approach has been wrong as often as its been right. All hes saying is often times the answer doesnt require science. The two approaches arent mutually exclusive.

[@lesscomplex6315]

The definition I like to give a good function, is a single transformation or transmission of data of the same structure or to a specific structure. I like this definition for "clean functions" better, since it gives each function a specific purpose, and it works on a specific structure of data. This doesn't imply that a function should be single responsibility, but more like single structure oriented with either transition or transmission properties. This allows you to create structures and their functions, then create parent structures that contain those structures and thus create higher level functions upon them. I find it very easy to work with. For example, if you're trying to create a report and this report has different data structures that are displayed on it, you can break down this report making function into functions of the sub-structures in the report you are making, then you can use those functions in the high-level report making function, which will handle their outputs to produce the report. This might be a very convenient way compared to what this book claims.

[@segueoyuri]

the thing about rules is that you should adhere strictly to them, until you know enough about the thing in question to know in which case it's best to break the rules

[@zxuiji]

23:44, I agree, with procedural you can see WHERE things start and end (with the exception of threading but going to have that problem with OOP too). Furthermore in procedural you can have your cake and eat it too, you want objects? Just make 'em and pass them as parameters, you want virtual functions? Just add callbacks to your objects or as parameters, or both even! There is 0 excuse for like OOP more than procedural, liking OOP more just screams you're incompetent at programming, pea brained or both.

[@therandomguy1701]

balls

[@ea_naseer]

deez nuts😂😂😂😂

[@applesthehero]

On the topic of small functions, I believe that a function should be at least a few lines long, with a few exceptions*, otherwise you've just added extra overhead to how much space your code takes up vertically, and how much the reader needs to jump around to see what your code does. A function should always be readable without scrolling, and should probably have no more than 2 or 3 indents * for example, a function which performs a mathematical operation that gets reused throughout the program can probably be written clearly in one line, and should probably be a function rather than repeating the formula

[@thisbridgehascables]

Yeah i just built a small web app calculation UI for special materials .. can’t give away what exactly it does .. since it’s not live. Yet, first round of coding later needed some refactoring or implemented into a small js framework for easier data abstraction and injection .. Even yesterday , I created additional functions to handle mobile .. it can really be hard to write clean..

[@ikarosouza]

I worked in a company where functions 1000+ lines were almost the norm, and I gotta say, it actually makes sense for them to be that big, the business rules involved are just that complex.

[@Kavukamari]

When you have a very complicated concept, sometimes it can't just be expressed in like 5 lines

[@khatdubell]

I currently work at a company where there are functions that are 1k+ lines. They aren't "just that complex", people just suck at writing quality code. Trust me, if i ever have to do work in that part of the codebase, they will be broken down into smaller, testable functions.