Stop Recommending Clean Code 

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.

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.

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.

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

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

"Right click -> format code" is clean enough

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.

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

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.

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.

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

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

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

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.

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

“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

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 😂

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

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.

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

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.

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.

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.

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.

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.

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.

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.

flip's doing a fantastic job

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.

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.

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

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

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.

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.

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.

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.

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.

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

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.

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

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

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.

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.

Damn I like what you're bring up. You're job much important to us, keep it up!

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.

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.

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

2:24 I love one comparison which our teacher taught us. You don't want whole bread or breadcrumbs but slices of it.

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.

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.

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.

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.

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.

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"

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

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

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

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.

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.

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.

Flip in fact, did not cut it out lmao

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.

I love crawling through fifty layers of abstractions to get to the code that actually does something

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

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.

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.

A function that inserts or replaces a key value pair in a sorted tree and returns whether the same key existed before. A good example of a function that both does something and returns a query result. But it makes sense since doing the two things separately will be twice as much expensive.

I like to have this "orchestrator " function that uses the smaller ones to build the narrative - this allows for smaller pure functions that do not alter any state and leave the orchestrator with that job. Although I can see this only working for "service" classes and such, not if your class actually represents an entity, for example PushNotificationService & UserModel.

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.

Unrealistic Code beauty standards in 2023 ? Nahhh

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.

Great advice! I was using print width wrong all this time 🤦‍♂️

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

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.

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.

Life's a Tennis Racket - there's a sweet spot in the middle.

Clear Code > Clean Code

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

My manager just recommended this book and now this pops up on my feed

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.

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.

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

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

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

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.

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

One of the things Bob Martin doesn't do in this example for some reason is split the thing into two classes, for suite and non-suite ones

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,

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.

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.

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.

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.

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

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

My preferred style involves using sequentially increasing numbers as variable names and raw pointer arithmetic instead of abstract algorithms or function names. I AM THE COMPILER!!!

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.

balls

A good litmus test to figure out if your code needs to be refactored, is if you can come back to the project, read the code, and figure out what is going on. If you can’t, your code has a readability problem and you need to refactor. How you refactor is up to you.

Great video! It is amazing how the Clean Code dogma started to crumbling recently, thanks to some videos by Murattori. It took time, but we may end up in a better place. By the way, how did you do to show the keys you pressed when navigating Vim? That was really cool!

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.