The Clean Code Debacle and Rhetoric Tricks - Casey Muratori vs Mr "Uncle Bob" Martin
HTML-код
- Опубликовано: 18 сен 2024
- Links to everything discussed in the video:
• "Clean" Code, Horrible...
www.computeren...
www.computeren...
/ 1631187145762443269
en.wikipedia.o...
en.wikipedia.o...
en.wikipedia.o...
cleancoder.com/...
odin-lang.org/
jangafx.com/so...
gist.github.co...
number-none.com...
en.wikipedia.o...
en.wikipedia.o...
/ 1155886656131649536
/ 1631423867183824897
/ 1633222004030464000
/ 1630720351914057729
/ 1633648294193668096
/ 1631281056199442434
/ 1634230283225448450
/ 1631277384748916737
/ 1630941755938881539
github.com/cmu...
pkg.odin-lang....
/ 1631627682667544577
/ 1632853028272316416
Website: odin-lang.org
Email: youtube@odin-lang.org
GitHub: github.com/odi...
Patreon: / gingerbill
Twitter: / thegingerbill
RUclips: / gingergames
One metric for readability is how often you have to jump to a different file or function to figure out what's going on. One of the most annoying things for me when I try to read code in packages I am unfamiliar with is having to jump down 5+ rabbit holes just to chase down what's going on for 1 simple function. So often I end up having to understand %80 of the package structure just to understand how 1 feature I am using works. I prefer code to read like a book as much as possible, and books don't send you to other parts constantly.
THANK YOU
Yeah the whole "you dont have to know the internals" thing goes right out of the window the literal moment you find out that you do, in fact, need to know the internals.
When your design requires more than one page to describe, wiki-style fragmentation of ideas is more manageable. Imagine reading through an entire chapter of a book to find one detail about one subject that you could have more easily found if it wasn't couched in paragraphs of narrative necessary to make it "readable like a book". It all depends on your requirements: you wouldn't write a wiki to describe the contents of a college term paper, and you wouldn't use a linear presentation medium to describe how a great variety of objects relate and interact.
Code should be written the way it's designed. If you're designing something large and complicated, clean code paradigms are more appropriate. If you're designing something simple, you'll only complicate it by following those rules (especially polymorphism). The problem with any programming advice given these days is that no one prefaces the proposed approach with "know your scope and requirements first, then decide how to tackle it". That said, the "clean code" approach is better if you don't know your scope. To refer back to the design analogy: generally it's better to start your design in a wiki, assuming it'll grow to need that flexibility, than to start it as a book and later regret its linearity.
"One metric for readability is how often you have to jump to a different file or function to figure out what's going on. One of the most annoying things for me when I try to read code in packages I am unfamiliar with is having to jump down 5+ rabbit holes just to chase down what's going on for 1 simple function"
I agree at least in the case there you have a large function which does step A,B,C,D in that order and A,B,C and D are things that were not needed by any other function it does not make sense to create for separate functions A,B,C,D which when are called by the main function which only consists of functions call for that 4 "sub" functions.
The only advance of that approach might be that the function names of A,B,C,D are telling you what each of this functions does but that could be also done by putting this as comments in a long main function.
Then splitting up such a large function into several sub functions only for the reason to make the function small you add the problem that to understand the code you have to jump arround in the source and if you are trying to understand the subfunctions you might have to find out from where they are called while in a large function which does A,B,C,D in a sequence this is very clear.
It is IMHO always a good thing if is possible to see the control flow of a programm easily and that is for me the biggest disadvantage of object oriented programming that it is somethings very hard to understand which code is executed in which order just be looking on the source - as the same method names may occure in multiple classes and you must know the real class of an object to know which implementation of the method is really called but you cant see that by just looking on the declaration of an variable in the source code.
@@elkeospert9188 @Wourghk I was mostly trying to suggest a quantifiable metric that can be measured. Given that metric we can compare coding styles and see what's better.
I did follow that up with my opinion based on my own experiences, but I do think it is inarguable that humans understand and remember things better that are in more of a procedural or story format. Therefore, every time you have to stop your explanation of a procedure to explain some abstraction you break the flow and make it harder for humans. At the same time it is helpful to be able to simply name a sub-procedure and say that instead of describing the whole thing. For example, you don't need to describe how to butter toast or peel a banana as part of a recipe. The line for when to name a sub-routine is of course going to be colored by opinion. Similarly, common abstractions can make things easier to understand or read if you are familiar with them, but are obfuscating if you are not. "Common" is going to be colored by opinion again. If you are all about OOP then certain patterns will be more understandable, but if you are aren't then they can be obfuscating.
In general it seems to me that OOP is overused and is more obfuscating than enlightening. I've seen many demonstrations of people taking code I can read and understand as is and then torturing it into a class that I don't and claim it's better.
"generally it's better to start your design in a wiki, assuming it'll grow to need that flexibility, than to start it as a book and later regret its linearity." This sounds good, but in practice it's impossible to predict exactly how things will evolve in the future. Some parts you will know to leave open for feature expansion, but you don't always know from the start what might happen in the future. I actually prefer to write things linearly and then only abstract and expand as necessary. It can also be difficult to design completely before beginning. I find it easier to focus on writing the simplest case and getting it to work, and then abstract and make things flexible from there.
A lot of frustration and confusion could be mitigated if developers just described their classes, methods, and functions in words. I generally drop comments describing what my intention is above sections of code I know are hard to follow. I also add things like this to code I inherit. It has helped me when I have had to come back to things later.
12:08 "A politician level when it comes to rhetoric" ...
Absolutely. I was kicking around and quite active in the OO and Patterns communities back in the 90s. I've been involved in numerous discussions with people like Bob, Kent, Ward, John Vlissides, etc from the early days of XP. (For context, I used Rational Rose when it came on a single 3.5" floppy).
You need to remember that Bob Martin is primarily someone who provides training and books, not who actually writes code for a living. He tried consultancy for a while (Object Mentor was his firm), but that didn't last.
If you were to trawl through the old usenet archives like comp.lang.c++ or comp.object from that era, you would simultaneously see him developing the skills and others getting pissed off with him.
He's a classic example of one of the tragedies of Software Engineering. Methodologists are the televangelists of the industry.
Look at what has happened to agile itself. Today, at least in the valley, it is much less a way to develop systems, than it is a way to sell books, consultancy, and training. I speak as someone who has seen (and used) everything from Jackson (COBOL in the 70's), through Yourdon in the 80s, XP and the explosion of OOA/OOD and design patterns in the 90s and, currently, Agile.
Yes - judge a persons knowledge by looking at what they have made. Where is something we can look at and be in awe of how well it turned out.Oh, whats that? Nothing? No wait, here's something... whats this - oh the C3 project, an accounting system that balooned to millions of dollars, massive amount of team members, and in the end took days or even weeks to run? Wow, what a sparkling diamond on top of a coding turd mountain! The trouble is the GoF are THINKERS, they are not DOERS. This is what happens when thinkers create new tools for people to use without having any experience of building things themselves. Disagree? Then show me something they have made!
Dark history of Westminster of Software Industry
"it is much less a way to develop systems, than it is a way to sell books, consultancy, and training",
I guess ... we'll have to develop the systems *ourselves* after all?
@@AloisMahdal Nooooooo....
I remember watching two an hour and something long talks by Uncle Bob some time ago and I remember how during the whole thing everything sounded about right, but then when it was over I was left with :
"Ok so what do I take away from this? I don't feel like I've learned anything of substance that would help me make better software, but it sounded nice while he way saying stuff."
That's when I started thinking this was the scam. He IS exactly a politician, goes up, says a bunch of stuff, sounds good enough, but doesn't actually say anything worth a damn.
At some point he mused on how "people weren't doing solid or object-orientation right" and that back when him and whoever else were doing stuff they had a different idea of how to actually do it and I was like "Oh ok then, uncle, please enlighten us HOW DO we use this the currect way exactly?" but he didn't elaborate.
Now Casey, on the other hand I've seen some of his stuff and I was able to actually take away some real, tangible lessons that improved the way I do things a bit. So if its a matter of any kind of dispute between the two I'm on Casey's side simply because I tend to agree with the things hes saying and I've built a very poor opinion of uncle Bob over the years.
Not only that, but I often feel like Martin’s approach is generally worse for programmers. I’ve wasted so much time trying to fix weird bugs in dependency injection systems and had to spend so much extra time trying to find code in the polymorphic systems (I find the interface quickly, but it’s harder to find which implementation has the bug - and generally each implementing class splits it’s logic across five other classes). Enums, switch statements and if statements aren’t just useful for performance, they’re useful for the programmer as well since they help keep related logic in the same place.
Also, in every “clean code” codebase I’ve worked in, most types added to the system aren’t needed for the problem. They just exist for following “clean code”. Many of the types would be better replaced with functions and if/switch statements - or even just by taking the few lines of actual code and inlining it.
I find the term “clean code” weird. It rubs me the wrong way. “Clean code” does not mean functional code. If I had to hammer a nail in, I’d take a dirty hammer over a clean spoon. Sure the spoon is clean, but it’s not functional for hammering a nail.
I've read a lot of Bob's books and I think they are very good. But the thing he's really good at is providing some guidance for programmers about professional conduct and principles. I've actually never cared about particulars in his code, since most of it seems antiquated.
I knew "Uncle Bob" was a clown, but a snake-clown? Unexpected! Ever since I saw his presentation on code comments being evil, I've dismissed him out of hand. Maybe his little straw man would represent bad comments, but you can state as much in a couple of minutes. Getting paid to spend an hour on stage to rant about comments though? That's just a glorified circus performance.
Programming is the business of creating form and structure from nothing. It's often difficult to know where to begin, how to lay a foundation etc. Well intentioned diligent programmers will seek any life boat in the infinite ocean of possibilities making them susceptible to false gurus peddling "best practices" and getting sold on "truths" that just aren't so. Some of these idea are generational and sweep the entire industry and we all have to ride these waves. It is amazing but also refreshing to see fresh ideas challenge entrenched ideas with real data leaving "gurus" to bloviate about aesthetics and productivity metrics.
@@herrpez Clean code do not needs comments. You describe the solution by well organized well named methods and variables. I delete comments everywhere, except when it explains a concept and not the code itself.
Great video. If the point of "Clean Code" is that it optimizes the experience for the developer, then I find in many cases it falls into the "premature optimization is the root of all evil" camp. Early in my career I saw lots of services containing eight layers of abstraction through three different modules with everything dependency injected through magic XML configuration, and at the time I was inexperienced and accepted that it's just "what you do to keep things clean and extensible." The code was "clean" in the sense that yeah, if we wanted to inject new functionality we easily could; it would probably be a dream for the developer that would add that code. Years went by and nothing was added; the code as it stood was fine and served the hyper-specific business need that it did. All the "cleanliness" did was make it harder to reason about in the future. Any changes we did end up making were in the business logic ends of the clean code abstractions; we would've lost nothing if the business logic ends were just directly connected because we only ever had one or two implementations of any abstracted away subunit.
Isn’t Xml a Java and C++ thing, in Smalltalk and Python and Lisp the code is so short you wouldn’t really use it or use json/ sexpressions. In these dynamic languages the classes and modules and methods and calls are all objects that can be manipulated, you could create decorator functions that do aspect oriented programming or in lisp better yet custom compilers so you don’t need xml frameworks or whatever.
@@aoeu256 modern Java frameworks do not need any XML for the CDI configuration.
when they turn away new developers for not respecting the mountain of stupid shit abstractions that is not easy to understand for the new guy(and doesn't make any sense in regards to the future) just like you said. thats when i have a problem with them. they wasted a lot of f*ing hours building that mountain of stupid abstractions and this is immediately visible when a new guy is required to implement a new feature and he says he doesnt understand it and he doesnt need it. right??
great and important example.
it shows how lot of effort can be "wasted" by optimizing for the wrong thing.
it also shows how post-mortem (years went by) analysis can often so clearly show *which* thing ended up being wrong to optimize for.
the million dollar question -- how do you know in advance? how do you develop a good strategy for answering questions which the engineers who wrote that codebase probably had: how much abstraction is too much, or when are we guessing too much into the future?
Yeh clean code metrics without correctly focusing on the things that will change is very dumb, if its a car company, don't expect it to suddently sell fucking apples
There are several problems that I have with TDD.
One is that to have full test coverage on any module, you need to create numerous tests for every state *transition,* and a singular module can have *many* states. Take for example, a simple stack. Test case 1, you need to check all of the member variables to make sure that the stack is initialized properly. Test case 2, you need to check the top stack item to make sure that the program sanely handles doing so on an empty stack. Test case 3, you need to attempt to pop the stack to make sure that the program sanely handles doing so on an empty stack. Test case 4, you need to attempt to push the stack and ensure that the stack depth is properly increasing afterwards. Test case 5, you need to make sure that the item that's currently on the top of the stack is equal to the previous item. Test cases 6 and 7, you need to repeat test cases 4 and 5 to make ensure that successive pushes are working properly. Test case 8, you need to keep pushing stack items until the stack buffer is resized and then verify that the items in the newly resized buffer are all correct. That, or just to an isolated test of the stack resizing procedure. Test case 9, you need spoof the alloc function and replace it with one that fails so that you can ensure that the stack resizing function gracefully handles a failure to allocate more memory. Test case 10, you need to make sure that the item pushing also gracefully handles a failure to resize the stack buffer when needed. Test case 11, you need to pop an item off the stack and make sure that the stack depth changes appropriately. Test case 12, you need to make sure that after a pop, the new top of the stack is correct. Test case 13 and 14, you need to repeat cases 11 and 12 to ensure that successive pops work correctly.
A stack is quite literally the *simplest* data structure I can think of, and yet, bar minimum, we're looking at 14 test cases with probably around 400 lines of code to test something that can be implemented in like < 10 lines of code. Imagine now, doing this for a more complicated object that has 20+ different states. If you did this for an entire project, 99.9% of your codebase would be nothing but tests. And you're spending potentially *hundreds* of hours writing code that doesn't actually deliver any features.
This then leads to my second gripe, which is that the second you need to change the structure of *any* object or the behavior of *any* function at all, you need to throw out all of your old tests and write new ones. It immensely slows down the development process.
Third, there's just the simple fact that many things *aren't easily testable.* Consider, for example, that you're writing a triangle rasterizer based on the Bresenham algorithm. How do you test whether or not the triangle splitting is working correctly? Do you sit down with pencil and paper, draw a diagram, work out the linear interpolation for binary floating point, and compare your hand calculated value with what the computer does for a mock triangle? Maybe. Well how do you check that there are no gaps in the seams between triangles? There's problems like this all the time, where the easiest way to test it is to just run the program and look at it with your own eyes. And keep fiddling with the algorithm until it *seems* like it's doing the correct thing.
Bob's livelihood, his persona and his ego all revolve around Clean Code. He will defend it by any means possible.
This is exactly what’s going on
His stuff is too pedantic and over generalized and lacking nuance
It has good use in certain cases And some general tips
I find his lack of stressing that code should primarily shout its intention, so someone ELSE will understand it, and this requires experience to get right or very good feedback with that same goal of revealing intention
@@ChrisAthanas And in that sense to find the ideal solution for a new problem odds are very high you'll be required to do multiple iterations least in the early stages.
@@duncanshania yes the creative process is inherently iterative, software is never finished, only abandoned.
Note that what this guy considers OOp is different than dynamic OOP, he said by writing stuff In OOp his code is 10x longer, this is Java style class OOP with lots of patterns needed because of the low level nature of the languages. In python or ruby you can use OOp even without writing classes, you have method missing, properties, class and method decorators, closures, json, first class modules and reflection that is easy to use.
Also inheritance isn’t dynamic polymorphism, you only need inheritance in class based static OOp. Martin says prefer composition over inheritance, and in dynamic languages you have duck typing for polymorphism, and ocaml has structure polymorphism.
Bob should try to measure how much jumping around the code a programmer has to do in order to actually read a piece of code when its spread in a gazillion functions and files. Believe me, it's a nightmare every time I join some project where I do not know the code to try to figure out how stuff works. My editor has like 30 tabs open just to read a red line of execution and I have no idea which one I put the breakpoint in and if I press the wrong tab, how to find my way back. If anything I had to learn to use the development tool way better than I did before. My rule is, I only separate stuff into a function if I see that two methods need this with a minor variation that I can pass as a parameter, if not I never bother as it takes the code out of where it is actually used.
I recently did a Javascript game engine for educational games that supports 5 different game types. I have 9 files. One for a "from the ground up" developed game framework doing all the dom manipulation using plain Javascript, one for the actual game engine implementation using this and one for each game style. There is also one html file (never touched as it has one container tag), and one css file. Believe me, to work with this is extremely simple and I can actually have all my source open in the editor and know where everything is. I use the editor scope collapse all and can practically see every function title in one screen height to quickly find whatever I am going to work on. I have fun and enjoy coding whenever I work on this, and is facing depression every time I have to join some 2000 source files project. Also not using any framework whatsoever is such a great feeling of achievement, plain Javascript, html and css. No mucking about trying to get around whatever someone else did in some endless node_modules pit.
That's why the functions should have high cohesion. If you have to jump through many functions to understand the whole they probably shouldn't have been separate functions in the first place and your design/separation is completely wrong.
OOP always comes down to "find those 10% of the code that actually do something"
Don't get me even started with enterprise software where they include definition of the loaded code in xml. Now we can choose which of the defined and overwritten definition should actually be called. A nightmare ...
@@chunheguo9230 that's call CDI configuration.
What product do you sell?
been programming for 45 years. Bob is a salesman he is arrogant enough to argue his point even when he is wrong. Most programming practices are religious in feel and inquisition in policy. The only thing I care about is speed and the amount of time spent to achieve that speed.
"The only thing I care about is speed and the amount of time spent to achieve that speed." So ... how is the teamwork coming? Code is communication with the other people in the team. If you want speed, why not a bigger machine? Unless you are coding in (MISRA) C for embedded systems of course, where every ms counts (computing on low-frequency radiation hardened spaceworthy CPUs?)
@@SterileNeutrino NO code is about solving problems. My computer today is about 10000 times faster than my first computer. It isn't about hardware it is about coding for speed.
@@GarrethandPipa You’ve been programming for 5 days bro stop capping
@@SterileNeutrino Endless thousands of lines to maintain game engines and game systems work (trust me it's way harder than the dinky shit most app/web devs do conceptually they just have shittier frameworks to use generally). A clear need to communicate effectively with other readers and explain usage, planning for long standing product lifetimes, trying to process ideally hundreds of MBs of data cpu side per 16ms, on time, without ever lag spiking, I'll tell you exactly how OOP generally goes. In all my years, i've never found a library utilizing OOP in ways that actually improves maintainability. There is only two examples in my own stuff, that it somewhat made sense, and they were extremely tiny blips in my entire history of coding things. And it wasn't much a difference anyway. Not to say that OOP is always bad, my god it's not, but everyone's using it like it's the silver bullet to all architecture when it's usually the least useful tool. Helping indies make games over the years there's two common patterns they resort to, Actor pattern and CS pattern, both of which are amazingly useful to bang out quick prototypes for say game jams where you only work on a project for at most two days. But every dang game project i've assisted with using these patterns starts to fall on it's face after just two weeks roughly of dev time. Every flipping time. Modding games using these patterns is always hell. It's not just terrible for runtime, OOP as a whole is vastly inflexible and not very modular. The work i do is about 80%, hell maybe you could say 50% as fast as folks doing everything the OOP way the first couple days, then time goes on, i don't only get on even ground but i end up 10x more productive month 1, by a year it's over 100x more productive both with runtime and with maintainability. now not to say that data oriented programming is hardcore the true silver bullet either but something's vastly fishy when i manage to make code that's very easy to understand, modify, and add to at a seemingly even rate with the runtime differences. Maybe it's not entirely true, but there must be something to the idea that "the problem was always the data". OOP generally forces things to become way overly abstracted without any useful utility for no reason aside the idea that people think things like, "here's a dog, and in real life it barks", when the reality is no that's not always the case they do this at first seemingly conditionally, they can't do it without oxygen, god knows what happens when you change the gravity of the planet they are in. or remove their voice box, these things are edge cases. Reality works more such that the same universal logic is applied to the universe in totality but it's the DATA that's different. and driving what we call "immersive behavior" is extremely easy to do when you drive it via data rather than typing mixed with edge cases. I've flipping had it trying to work with most indie game indie developers over promising and acting like their way of doing things would surely allow them to accomplish their AAA big shot dreams when they can't even grasp that their programming patterns is exactly what's holding them back from reaching that goal, instead of being willing to improve themselves and redo the entire backend like what's truly required, nooooooo what they prefer doing is pretend to improve things and keep promising things they can't deliver, looking innocent all the while, no matter how many times mod developers point out that the foundation is just too flawed they don't listen. And to a point i don't blame them for not listening. I went through the OOP phase. It is a common phase. The deception is that it feels soooooooo easy to use to write super simple prototypes that you feel a productivity high and think that must be the way to continue doing things, ever wondered why your pace slows down with time the more the code base grows? THIS IS WHY!
@@GarrethandPipa If working in groups you do need to be mindful about maintainability probably and all that it's just OOP doesn't reach it (damn i love to repeat myself), and i don't think i've actually felt comfortable grabbing better hardware to make up for code base with a shitty ass runtime that feels beyond sick. But indie devs using say UE do this crap all the time. But i'm probably making hyperbole assumptions.
One of the interesting aspects of Uncle Bobs parts is that he basically goes through his talking points he uses almost 1:1 in his talks and presentations. As he got to the end of his talking points, he claims to not have much more time for the discussion.
You're right about the rhetoric! It's everywhere. Right on front of the book is this manipulative beauty: "Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.". Translation: either obey our rules or be expelled from the industry!
Consultants (like Object Mentor) are a lot of politicians when it comes to the use of manipulation!
Regardless of anything else, Martin not having watched Casey's entire video before their talk is WTF
It wasn't a "Clean Video"(tm)
I watched the entire video of Casey trying to make sense of it, and it doesn't. Casey is like McGuiver, he invents stories and calculation saying how bad is clean code because he can write a function more performant. He forget the software needs to be maintain, scale, many people work on that overtime, so it needs to be easy to read, and fast to deliver features.
Sure, when I do my personal project I write them just for me to understand not for a team.
@@albanx1 man... I wish there were more people commenting things like what you did. For fuck sake it looks like many developers never worked in a software house with more than 5 devs... It's embarassing. Then you get them in your company and suddenly the code becomes shit and they just pref to leave and start screaming about bad code ( the same bad code they wrote as well ) pointing out at clean code as the main issue.
Sure, clean code has some chapters which are quite outdated, but it's so annoying when those devs involved in microscopic scope or products are going full "What of a scam clean code is?" just because there's a lack of discipline. I have countless of examples of how things applied through clean code improved the overall productivity of many teams I've been involved in giving us time to spend on features than bugs and other shit. And I'm a software developer, just in case someone would argue the same thing about uncle bob not being a real dev.
You do know Casey has written quite a lot of software in a corporate environment, yes? Software that was written 10, 20 years ago and is still used today.
Uncle Bob is a real pro at what he does, which is very good for him... Probably unfortunate for programming community.
the audience of each philosophy is VERY important.
"Uncle" Bob's main audience is business/enterprise developers where most code is modeling business processes that are added to and changed constantly. Where structure is king, clearly delineated boundaries of logic are needed. Where, historically, you deal with very poorly written and highly confusing procedural code baked into form code behind files in upwards of 10k lines. These are some of the core motivations for creating a culture of "clean code." Where OLTP transaction "performance" is a secondary concern to having very readable extendable code.
It’s all ALLL context depending
From what I've seen in practice, Clean Code:tm: bases are overabstracted and are very hard to read and navigate. The code might be extendable, but it takes so much time to find what and where to extend that it would've been faster to update the procedural code.
I agree about the need for clearly delineated boundaries. But it doesn't require Clean Code:tm: to achieve.
@@etodemerzel2627 Are you talking about Python, Smalltalk, Java, or JavaScript? I think Java had a bad history of forcing classes onto people, when closures reduced the amount of "indirection", and it didn't really have the flexibility of being able to substitute stuff for other stuff. Multidispatch and "aspect oriented programming" isn't too hard to do with stuff like methodmissing and function decorators.
"the audience of each philosophy is VERY important." Indeed. Some audience may have as a primary concern the discovery of the minimal arrangement of machine instructions that gets the job done in the fastest way possible. Another audience may have as primary concern minimising the cost of development whilst getting the job done, that includes keeping the code simple, readable and easily modifiable.
Problem is slavish following of the principles of CLEAN sacrifices the former concern and fails to achieve that latter concern. As pointed out by looking at Bob's example code made of dozens of tiny functions. Likewise slavishly following DRY or the banning of GOTO.
in reply to most of the replies. the motivation is to overcome large procedural code bases with sloppy spaghetti code. Does Clean Code in it's purest sense fix this? i would say no, not in it's purest sense but to me it's more "food for thought" than anything else because the run of the mill par code that does exist needs something. I have struggles with the same concerns most of you have. One thing is for sure, knowing design patterns and when and where to apply them does help, knowing functional and OOP style programming also helps. Fixing everything with a hammer because that's all you got doesn't. Writing complex incomprehensible almost assembly like code every case in enterprise code is not going to work.
Casey is an absolute master of respectfully extracting the truth from very opinionated people, breaking down walls, and having a mature debate/conversation. Thanks for covering this so thoughtfully and thoroughly, Bill!
Yeah I like how he politely but firmly sticks to the point, never taken in by the rhetoric.
Casey 100% isn't that. Tried multiple times to engage in conversation with him on twitter and to try and explain why his example is bad based on my view. He responded ZERO times and just blocked me ¯\_(ツ)_/¯
@@nafakirabratmu It was not *his* example.
@@nafakirabratmu can you provide an example of the topic and your arguments?
@@nerdError0XF For one, his example may look good, until the moment you want to expand it so it to compute the area of an object that can't be generalized as an x*y*z a pyramid or a cuboid for example.
Another point is while the CLEAN code is 10-15x times slower in this example, in reality there's a static overhead of 30 CPU cycles. If you change the logic from computing an area (a couple of multiplications) to lets say calculating secure hash or encrypting/decrypting data or even fetching data from a source local storage or over the internet, the performance difference (30 cycles) difference would be negligible
A person's writing reflects the clarity of their thinking. In other words, writing _is_ thinking. I'm glad this discussion was put into writing because Martin's convoluted writing perfectly captures the nebulous, unclear thinking around "Clean Code."
I am so glad to see this type of discussion get more spotlight. It can only lead to good things as more programmers become aware of these other perspectives. You guys are putting into words those misgivings so many of us have felt for years but couldn't articulate. Keep at it!
Writing is itself a transcription and condensation. Logic (logos) and language are not two sides of the same coin, as some of the ancient Greeks considered. Nor does thought need to occur in language. Lastly, there are two macro types of minds (conscious and unconcscious organization). The singular mind and the divided mind. The singular mind is biased towards linear convergent thought (deductive, interpolative), and it maintains a more concrete and rigid "default anchor reality" to weigh incoming information against. The divided mind has a mixed bias, but the overarching paradigm is non-linear divergent (extrapolative). There are several different minds and perspectives working in parallel, usually with a superstructure ("higher self") which keeps track of as much of it as a it can. working with the "core self" to sample from all these pieces and organize output. Hence, non-linear and divided. The two types differ most in the sense of reality that they maintain, and their response to cognitive dissonance. In general, the divided mind is more apt to ignore superficial contradiction and not experience dissonance, so results really come down to how well constructed the higher layers are so far as their ontology, epistemology, error control, how concerned they are with truth (goals). The divided mind does not exist submerged in language, it functions through a more base symbolic language. Language is a layer that it functions through, not its actual mode of operation.
Hence writing is several layers of transcription. There are different types of writing also, as there are different applications of one's "theory of mind". Writing only partially reflects the mind, as minds are generally compartmentalized no matter the type. They have stable macrostates and personality constellations that can be primed, sensitized, brought out by different environments, and so on. It's not a reliable or direct measure of the mind itself. You need a lot of input over a long period.
Not that this reply really has much to do with what you were getting at, but regardless. It does relate with the rhetoric and psychological tricks stuff the video is talking about.
@@Acetyl53 and realizing all this is mostly why i doubt just because an AI talks doesn't mean it's truly sentient, nor is a person incapable of generally talking clearly actually intellectually lacking as the average person is. Not to say that language skills aren't important. Or a simple example might be autism which i proooobably have. But i've seen the subconscious mind picks up on a lot of things even if a lot of it doesn't make sense. It's entire design is to randomly reach into every direction and search for something.
I'll contest this, I struggle with getting my ideas down in a rigid linear fashion / explaining them but my ability to explain an idea is uncorrelated with it working when I get frustrated and "just implement it" instead. If you think the ability to make something sound convincing directly correlates with having knowledge you're going to get sucked in by silver tongued charlatans.
Just because you can't measure something (The persons understanding is not something they can readily translate into language) doensn't mean it isn't there.
@@Acetyl53 It's funny you say that in such a long message.
I think you're wrong - and while I'm not always able to be brief, the Spartan way of laconic speech tends to be indicative of clearer thinking and communication skills alike.
@@michaelmoran9020 What was said, is not what you're attacking. The ability to communicate something is related to the ability to think about it to begin with.
I've been in the situation you describe plenty of times - but I still see it as a lack in my ability to formulate my thoughts, or even finding the right thoughts to convey. Doesn't mean I don't know the solution to a problem; it just means that my ability to think of communication is what is unclear.
Which is what the original post here was getting at too. But clearly, since "Bob" has no trouble communicating, but rather has great trouble being honest with himself and others, it's clear that "clean code" is itself a muddled mess - whether Bob initially believed it wasn't or not.
I don't think Bob is actually attempting to communicate muddled thoughts here though. I think he's trying to muddle the waters on what is now a scam, if it wasn't before. He is either willfully lying or has deceived himself - either way, he is lying about clean code, trying to sell poison as if it were the best of wines.
20:40 An overengineered bridge made to take 10 ton trucks might take a 15 ton truck without failing, but "overengineered" code rarely has the analogous quality. "Overengineered" code would usually be better called "overcomplicated", "oversized" or even "overwrought" 😉
100% test coverage
@@Sammysapphira 100% test coverage, but fails 10 seconds into production, because the tests don’t model reality.
aka Java
@@_slier JDK developers have mantra - When in doubt, leave it out.
However Java developers following Uncle bob mantra are overengineering
I personally prefer to use the word "overengineered" in the positive way because the only word i can think of when people overengineer things in a negative connotation is "enhancement resistant"
Inflation reduction act of 2022 is such a ministry of truth moment.
How so?
@@5ystemError Because it didn't really reduce it. I didn't want to get political with this, I just thought it was a great example.
@@nexovec Right well something doesn't become Orwellian just because it fails to achieve its objective.
@@5ystemError It's exactly as you say it is.
It's great to finally see somebody pointing out the rhetoric tricks of Uncle Bob rather than simply focusing on the flaws of Clean Code per se. Smells fishy. Thanks for the wonderful video!
I'd like to see an actual github repo where the argument plays out. One dir has the CleanCode approach where only advocates can contribute, and another has the OperationPrimal approach. And then each team updates the repo as the requirements come in. Then it becomes a benchmark that can drilled for data. Probably more time would be spent on the CC side, and it would be harder to maintain, read, debug, and use.
it would likely be the opposite (after all, that's what CC is supposed to help) but the performance would be awful
also, don't you mean two separate repos that do the same thing?
It all starts with CleanCode … and quickly descends into the full gamut of Agile rituals.
If someone even mentions SOLID, then reach straight for the flamethrower otherwise your entire teams productivity is in grave danger
I saw Casey's video when it came out and it was a breath of fresh air. Having started programming in Basic, C and assembly in the 1990s before going to university, I didn't really get the draw of SOLID principles which grew and grew in hype. After many years working with over-abstracted "clean" codebases it was great to see someone point out how much of those practices are backed by unvalidated subjective assertions.
the best paradigm is the GOTO paradigm / s
@@theinsane102 exactly. imagine using bloated concepts such as 'loops'
@@theinsane102Knuth Himself wrote a paper named "Structured Programming with go to Statements" and I'm _certainly_ not inclined to argue against him.
(The paper doesn't actually advocate that: by the author's own admission, the title was pure clickbait - in 1974!)
Unbelievably excited for this!!
I’ve seen both of them on RUclips. Didn’t know there was a “fight” between them going on.
Do agree with the other people here after watching Martins video I felt like I learned nothing and after Caseys I felt like I did learn something.
@@lefteriseleftheriades7381 > If you work on a project in the style of uncle bob, you will be happy working on it and maintaining it for years
Do you have any actual data for this, or is this just an opinion again? Because I've done both styles of projects, and I prefer the "high performance" style most of the time (for various reasons, mostly because jumping around from file to file to understand something is very mentally exhausting for me)
If you have *any* hard data that one style is better, more companies using a specific style succeed, or students writing "clean code" spend less time writing / create less defects / ... would be interesting. Heck, even comparing two companies in the same field, similar size, 50+ devs, to see which has more churn would be interesting.
I've looked for data on SOLID (if it was definitely better, I'd use it!), and, for example, the most-cited paper about how SOLID affects metrics *defines* that it'd be neat to measure how easy change is, but what it actually measures is "lines of code per function" and "functions per class" which is neat I guess, but I wouldn't judge a book by the number of words per paragraph.
The certainty that Rober Martin has, with few or no data is what always gets me. I have this gripe, and I had it with my university teaching "software engineering" as well, and I could talk about this quite a bit.
@@MeMe-gm9di This is my opinion after using SOLID for 5 years in comparison to the previous 5 years that I wasn't using it. Complexity is managed because the code is split into components. The code base is extendable because I have interfaces decoupling the components. We barely have 1 production incident every 2 years because the code is easy to understand and it is covered by unit tests. We refactor the code without fear because the unit tests tell us if the contract of the class is followed. Unit tests don't break because they are tested through the public interface not the internals. New developers can easily navigate to where they need to change because the architecture makes it obvious what the responsibility of each component is. If you watch one video of uncle bob, let it be "Robert C Martin - Clean Architecture and Design", It's really worth it.
@@lefteriseleftheriades7381 I have also tried using Clean Code, it personally hasn't left my projects in a better place. I've read multiple books about architecture etc, and all I got from it was a warm fuzzy feeling, but in practice, the specific advice given didn't hold up.
The act of thinking about software architecture is great, but I do feel the exact prescriptions were not particularly useful.
But hey, I'm sure I'll be told that I'm holding it wrong, and the fact that there's little (if any, and i looked) actual data supporting clean code is just because I don't manifest it enough.
@@lefteriseleftheriades7381 why would you need to refactor the code if it's "clean"
@@ruyvieira104 as features get added, you realize that you can reorganize the code to move methods to a new class. Whenever u bring something new to your house u need to tidy up. What clean code does is help ypu quickly know where a change needs to be made and avoids the risk of that change breaking something else.
"use descriptive names, everyone agrees to that"
Either you've been absolutely blessed in your programming career, or you haven't worked with a lot of people.
I suppose the 3rd option is we simply disagree on what a descriptive name is.
Agreeing people should do that doesn't mean that they will. I'm pointing out that this "principle" is not exclusive Clean Code:tm:, and everyone would agree to this even if those same people do not follow it.
And some people may think they are being "descriptive" when in fact it's only comprehendible to themselves. People forget how others will understand what their code says.
In Rust what does "expect()" expect?
The answer is refactoring. When I meet a code with bad naming, as I read through and understand it I rename variables, methods or if it is needed I extract methods as well.
@@banatibor83 that only works if you can get the rest of your team to agree.
Otherwise you’re fighting the tide.
One person cannot get undo the multitude of sins an entire team can commit
@@andrewdunbar828it expects ()
watching video. it's interesting. as an FYI, in OOP, a dependency is any interface (class, type, etc with public members) that you pass into another member (class constructor, method, property, function, etc) to be consumed by said member. dependency inversion simply means the dependent member will depend on the interface of said dependency, rather than a concrete type, which you can then move downward in the hierarchy.
Also (now getting towards the end of the video), dynamic polymorphism is not the same as inheritance. you can have polymorphism without inheritance (using composition), and most of the people I know who have tried it (myself included), prefer it over inheritance.
I think a "dependency" is even more general than that. It is any name/symbol/operator/function/etc that you depend on. You can 'invert' a dependency by changing the way you access it. E.g.:
int example() {
return 3 + 4;
}
Here there are two literal number dependencies. Let's invert them in some way:
int a;
int b;
int example() {
return a + b;
}
Here we inverted them by making them global, not generally a recommended way to do it, but an inversion none the less. More typically we'd take the dependent values as parameters:
int example(int a, int b) {
return a + b;
}
But there are two other dependencies in this code we could talk about. Let's start with inverting the operator:
int example(int a, int b, auto op) {
return op(a, b);
}
The other dependency we could talk about is the type:
auto example(auto a, auto b) {
return a + b;
}
The idea of talking in terms of dependencies is to highlight what we are tying our code to and how we might change it if we require more flexibility or rigidity and what tradeoffs that brings.
Your point about composition is spot on. "Prefer composition over inheritance" has been the mantra in OO programming for at least 20 years, yet so many taking Casey's side seem to not understand even the most basic of OO and act as if it requires you to make every line of code live in some deep inheritance hierarchy. For my own code, I would consider most of what I write to be OO, but I wonder what the people here would think of how little I use inheritance.
nah, a dependency is a 3rd party library :) . It is funny how people argue against something they do not even understand.
@oracleoftroy is correct, the way bob is using dependency is much more broad, but you could interpret it as module or package dependencies like import statements.
thank you ginger beard.
this is exactly what i was looking for.
i completely agree with the horrible performance that clean code has and also the point you made.
100% agree with both points.
Always hated Martin's condescending tone. Needed to be checked on his BS.
That was great to see the context around all of this! Bob seems like he's just trying to "win" an argument instead of communicating ideas to actually help programmers in reality.
Aside, I wouldn't mind a video discussion about the Odin roadmap and what's going on with C-Odin and the like :)
Well this is a great surprise! Can't wait to watch this.
Clean Code has cost me hours of productivity, arguing over the most pointless things in PRs. How can he argue it improves productivity
@@dispatch-indirect9206 Yeah, I think he agrees with David Farley on preferring pair/mob programming
@@dispatch-indirect9206 ...just that that is not mob programming. Dave Farley incidentally just published a video about it.
Dirty code has cost me many hours, having to completely rewrite the code, because it was a complete mess of spaghetti. With goto statements gosub statements, 6 level deep nested if statements and loops.
@@tabularasa0606 Indeed dirty clean code aka Clean Code tm has cost me a lot of time as well trying to fix other people's messes. All the lovely GameObject.Tick() methods hiding immense complexity and having numerous side effects because of course that's the right way to do things. Except when it comes to adding features and maintaining all that you end up with a mess that's a hundred times harder to deal with than using something akin to ECS least for game logic most of the time. But I will plainly say, goto statements and sometimes sadly even fairly nested conditionals are the best way to solve some problems. Not all for sure, but some. The important thing is to actually solve the problem in a way that doesn't use abstractions that serve no or negative utility. The approach you use therefore is going to depend on the problem itself.
"I am the creator of the Odin programming language."
Instantly subscribed.
just 13 minutes in, but those pivots of Bob Martin were extremely annoying when I've read their exchange. This alone has shown me, that Casey is right (to a degree). He has clearly shown that you can write simple (arguably simpler) code that is vastly more performant. He single-handedly shown that SOLID architecture is extremely costly and should be used only when it's actually justified, which clearly isn't the case today.
But in reality, the code isn't vastly more performant. Casey is tries to show you that the clean code is 10-15x times slower, but it isn't it's just 30 cycles slower. If the code wasn't calculating the area of the simplest shapes (a couple of multiplications) and it was an operation that takes (tens of) thousands of cycles to compute (hashing, encryption) there would be no difference in the performance. Another issue with Casey's code is that it's overfitted, he's computing the area of shapes that can be generalized as constant multiplied by two variables, thus it's easy to do it with a single equation, leading to simplistic looking code. The moment you try to extend his code, so it could calculate the area of 3D shapes for example And now imagine if you have to make it work for basic 2D, 3D shapes and then some irregular shape that needs a set of points and angles in order to calculate its area.
tldr; The only time "clean code" performance can be considered a downside is when you are writing performance-critical code (rocket navigation systems, OS kernels, 3d rendering engines)
@@nafakirabratmu I fully get this argument, but I have yet to see complex system that isn't overcomplicated by OOP. Casey has presented his argument many times, yet OOP counterargument isn't really out there. That is the issue.
Show me where OOP is the ultimate win. I'll wait. I was searching for it many times (since I hate having only one side), yet I didn't find any. Here, not my uncle was also unable to present an actual, tangible benefit.
I really want to see someone else making a countervideo to Casey. I really, really do. Yet, here we are. You are just saying that the indirection price is meaningless... that's not an argument. Casey obviously looses something going this route - so why is it so hard to quantify?
@@nafakirabratmuOOP programs are bloated and harder to maintain compared to procedural programs. This has been my experience and also shown in this video. Even if OOP was as performant, there is no good reason to use it.
@@NoX-512 There's a reason OOP is THE paradigm used in the last 50+ years. Don't get me wrong, I too don't like the over usage of OOP, but OOP itself isn't the problem. In my opinion the worst offender is inheritance, once you get more than 2 layers of it, things get messy and convoluted really fast. Composition seems to be a far cleaner and elegant approach to solving the same problem, and I'm not sure why it is so underutilized. There's a video by CodeAesthetic called "The Flaws of Inheritance" it is a must watch.
@@NoX-512 "OOP programs are bloated and harder to maintain compared to procedural programs."
It depends - if you already understand the existing code fully it is sometimes much easier to add a new functionality than in a procedural programm.
But if you have to maintain object oriented code which you not yet understand than it is in many cases harder to find out what is does than in a procedural programm where it is always clear how the control flow is (or in other words you always know which code is really executed than a function is called)
Object orientared programmers have the trend to make everything a flexible as possible - for example introduce a interface (Java) even only one class exists at that time which really implements this interface because ("you never know") in future there might be another implementation for the same interface.
If that other implementation later really comes it is a good decision - but if not it adds a layer of additional abstraction to the code which makes it more difficult to understand.
The problem with pissing performance away on the altar of "clean code" is that it adds up an it's a LOT of performance. We have supercomputers on our desks that take ages to open an image editing package among other absurdities despite having drive storage that's faster than RAM used to be. But another equally important factor is that this so-called clean code isn't that clean. Have you ever tried to read a complex OO project or refactor one? There is something profoundly misguided and dishonest about a lot of so-called best practices based on aesthetics and productivity claims. DOP delivers unambiguously and it's not about rhetoric, opinion or bullshit. It's objectively faster, easily by 10x - 100x. This shouldn't be a debate and yet the pied pipers who led an entire industry down this rabbit hole insist that their ill-reasoned philosophy should persist. I like Uncle Bob but I take issue with him starting every video with how he was around way back in the day and he's been doing this forever. I'm 55 and have spent most of my career listening to false prophets pontificating about best practices and feeling vaguely queazy about the whole mess. I'm at the stage where I am more confident about my ideas but still pragmatic having put up with a lot of nonsense. It is refreshing to see a new generation upset the apple cart and call bullshit on some false gurus who advocate overly zealously for one questionable paradigm. Argument from authority lacks credibility when one is the authority on a status quo that created the mess we all live with, as they blame that mess on aesthetic nuances that really aren't core to the central problem that created the mess.
The target goal to optimize is efficiency. And it includes not just CPU cycles, but also $$$ spent on programmers/debugging. Maybe when the programmers are eventually replaced by AI that aspect will stop to matter, but we're not quite there yet.
@@clray123 Different circumstances require different optimization goals. One thing you can be sure of though, when gurus pontificate about developer efficiency there's a lot of bullshit masquerading as fact. Some of the worst and most expensive failures in CS history have been administered under the auspices of these so-called best practices. Developer efficiency is the last refuge of scoundrels justifying their horseshit because on every other metric it makes no sense.
@@dorbie Just like performance, you can monitor and measure productivity. If you give a piece of code to five different programmers and all of them proclaim they are unwilling to touch it as it's incomprehensible to them, and it's only maintainable by its original author, as a business owner you are assuming a risk by making yourself dependent on that one person.
Maybe they are a performance genius, and that will offset the lack of their scalability in terms of labor division, but if they kiss your company goodbye, then you are left with all the shit they produced.
So either you have to find another "genius" to take over (and pay them a lot more than the "average" programmers), or you are shit out of luck. Another aspect is that these "geniuses" are usually only willing to maintain their OWN code, not written by some other "genius" (which they consider not smart enough). So you may be even more out of luck than you imagine when the "performance genius" disappears.
@@clray123 You just engaged in exactly the kind of fantasy scenario and rhetoric used to sell the usual bill of goods to pointy haired types about developer "best practices" that are more ideology than fact. Our industry is awash in claims and tautologies that are completely unsupported by evidence.
I'm not sure that clean code is even an appropriate name, and I doubt that clean code is primarily aimed at readability and ease of understanding. Rather, it seems obvious to me that it aims for maximum decoupling. However, maximum decoupling inevitably goes hand in hand with high levels of indirection, and high levels of indirection by no means equate to easy-to-read, easy-to-understand code.
This is why I repeatedly referred to it as "Clean Code:tm:". It's a marketing trick to make you associate it with what your intuitions are with (lower case) _clean code_. This is why I've focused on Mr Martin's rhetoric tricks.
Smaller functions has nothing to do with code review practices or trying to shorten the number of lines on a screen.
Its about looking at a function and being able to quickly grasp what its doing.
Its also
easier to test
easier to debug
easier to modify
easier to reuse
I'd not say it's always ideal either however it generally does have benefits like those. There are times doing that just bloats things a bit too much and it's for sure a tradeoff. I wouldn't say it's easier to modify if you're nesting function calling insanely densely yet the functions themselves are like one off use. And overall yeah it's not like we should take the points as constant ideal practices though there is a bit too much dogma in the air.
@@duncanshania yes. It can be taken too far.
@@duncanshania On the subject of dogma, i'm not a fan of dogma, but (and maybe its just me), i think dogma is learned more than its taught.
Take "don't use raw loops" for example.
When i hear that i don't hear "If you ever use a raw loop you're a terrible programmer and should not be given a task above that of a junior developer".
I hear "raw loops are less readable and more error prone, so try to avoid using them if you can"
Unfortunately, that doesn't fit on the side of a mug. so people reduce it to "Don't use raw loops".
Its sort of up to you to either know why, ask why, or look up why its considered a bad practice.
@@khatdubell Actually now that's a interesting point and might be somewhat honest to how echo chambers operate.
From experience, people praise small functions, up until the moment they need to debug an obscure bug, and they need to jump between many different files and so many different line numbers.
"Clean" code has never come off as clean to me. If anything it comes off as incredibly messy and disorganized. A sort of organized chaos. Like a kid shoving a mess under their bed.
It is the opposite of readable, takes longer to make it that way AND is slower. So as someone getting into programming the only parallel I could make for clean code is the Adeptus Mechanicus from 40k. Some spiritual worship of really bad technological ideal that people do because its done.
Except at least there it works unlike irl.
More ideological than practical.
Thank you! Great video and long overdue
In Software Engineering 2 class the professor is preaching Clean Code and SOLID. He promotes using design patterns in Java due to how "simple" it is.
He demonstrated the Strategy Pattern to us, where we would be able to switch out different sorting strategies to extend this one class. It took 9 files of Java code and was very very hard to read and mutated state everywhere... Basically the opposite of clean.
Meanwhile I proposed an elegant solution... Higher Order Functions. Simply pass your sorting method as an argument and return the result... THATS IT!
OOP has to be over complicated because it is a flawed paradigm.
Functional Programming mixed with some procedural and Data Oriented is the future. OOP is dead.
In general I agree with you. I'll also say that after ~30 years as a developer working at companies ranging from small startups to large corporations that most development organizations aren't far enough along the path to where arguments such as this are the most pressing topics. It's more like "functions are good, use them". Don't care so much whether big or small, but take out all this repeated copy/paste code, make a function that does that, and call it (I kid you not, one place had the same about 50 line boilerplate code repeated over 100 times throughout a large financial application). or "standards are good, let's not quibble on fine detail right now but let's all agree on some of the formatting basics at least and take it from there. Rinse and repeat. I've seen way too many ideological wars that continue on long past any point of positive returns and over points of ever diminishing value :) And no, it's not always the large corporations that are further along the path to "good coding practices" than the startups. But mind you, I still enjoy these discussions when I'm off the clock.
From one of Uncle Bob video I learned that clean code (or rather opposite of clean code) can be measured in number of "WTFs" when someone is reading your code :)
So as you see it can be measured.
But those WTFs will be very subjective. It's not a good way to measure it.
@@etodemerzel2627 there are definitely some objective WTFs. Either way...if someone else reading your code cant understand what is happening...that WTF is valid, obviously assuming they are familiar with the language its written in.
@@etodemerzel2627 Subjective WTFs _are_ actually a good way to measure it.
You're on a *team*.
A continually rotating team.
You should be trying to maintain a codebase so that random people don't have to look at it and scratch their head for an hour.
I prefer to keep people saying a continuous wtf while reviewing my code, so that’s just 1 x wtf :)
a) have they measured it b) where can I read the paper that compares “Clean Code” and not-clean code and measures it by numbers of WTFs when editing?
If there is no such measurement, after years of talking about “Clean Code”, why? Do people not care, or is it just not better?
While i find the discussion fascinating, i don't think this does influence the average programmers real work that much. Almost all code i've seen and worked with could have been both cleaner structured and more performant.
There's no need to pick a side.
half the android applications on the market are so poorly implemented they open with a 5 second progressbar and are so broken they lose data consistency between screens after each user interaction. "better state management". because the developers coerce every library and every practice to their idea of "clean architecture" their employers who dont see this are upset with the progress and they ask for the team to hire a new senior developer. and you interview with them and you tell them during the interview "i am not a big fan of clean architecture, if i ask 5 developers what clean architecture is i will get 6 answers in a good day. i ask what is the medium article you copied from? but i can remove the performance bottlenecks in your app, i see them". and a few days after the interview i get the answer i am inexperienced and they require someone senior :D the first app i worked on in2012 had 65 milion users and opened without any progressbar or splash screen. when this happens to you 50 times and you cannot find a job anymore and you cannot pay your morgage anymore (eventho you can make apps that run orders of magnitude faster than these dark rat "clean" developers) maybe you will want to pick a side.
I've been watching the debate and, honestly, I've started in Uncle Bob's team initially, but slowly got annoyed because of the arguments he was presenting. The idea of "clean code" (lowercase) from my point of view is that the code has certain characteristics that allow it to be easy to reason about and change and I always thought that's what Uncle Bob promotes. Yes, there are some cases when polymorphism is better than some gnarly switch statements or multi-level ifs, but I've always viewed it as more of a technique you can have in your toolbag rather than the default approach as I've always found switches clearer than polymorphism and dependency injection.
There's something I'd like to add regarding Casey's arguments: not all software is compilers, browsers, operating systems and so on. There's a wealth of software that we could call "information systems" where performance is less important than the ability to change. This doesn't mean that performance can be really bad, it just means that we can accept the software being 20x slower as long as it can be changed faster and that's one of the reasons why some people prefer languages like Python or Ruby (which is the language I use) over C++ or Rust, especially if there is a lot of I/O involved (it really doesn't matter if my code runs in 20ms or 1ms when the network latency adds 200ms and the database adds another 50ms). It's simply a matter of what's valued most by the organization and, at the end of the day, what they are willing to pay for.
On the other hand, Uncle Bob has been quite close to the Ruby community and even had multiple RailsConf keynotes and a lot of people have listened to him. One of the most common pieces of advice that he gave was that you should abstract away the framework or database you are using to enable change (see his "screaming architecture" blog post). But this came at a cost that Uncle Bob left out and it's very similar to what Casey is saying: when you abstract away the web framework you are using because "delivering via the Web is a detail and should not affect your architecture", you lose a lot of benefits that come bundled with the framework you chose because of those exact benefits, which will cost you time (aka "programmer cycles") and performance. However, a lot of people took that advice seriously and I ended up working with codebases that have hundreds of classes that build unnecessary abstractions over an ORM that is yet another abstraction over SQL. But, hey, the classes are small and there's a lot of dependency injection so the code *must* be better, right?
id just like to dispel this myth that bob martin doesn't know what he's doing, bob martin knows exactly what he's doing
Casey is an engineer, Uncle Bob is a politician at best. I know who I'd follow into battle. From my experience in the industry, the only ones actually taking clean code seriously are the agile product managers, that should tell you all you need to know!
One of the most pernicious things about "clean code" is that programs which use it often have "non-reproducible" bugs cause private classes may affect (infact clean code specifically tells you to do this on page spread 109) other part of your program without them taking any kind of responsibility for it. And thus the developers don't take responsibility for it either.
I am trying to reserve frustration towards Bob but I have no respect for the hindrance his teachings put on my education. With a whole industry brainwashed even when working in AAA its painful that one persons lack of admission to a failure of lifes work ruins any chance we have at making meaningful progression by breaking this social contract of just coding what matters and leaving behind this false dichotomy of crap.
I am going back after 12 years of being stuck in this crappy mentality and now coding like I should of from the beginning. Something always felt off and with the entire industry pushing you to code a certain way and with some personal difficulties in life you don't take that extra second to pause and reevaluate until you have that moment. Now I feel all this productivity and time wasted to realise the answers were always so much easier and enjoyable and not rooted in deception.
with clang -Wenum will warn you when you forget to update your switch
A trivial matter to add more CPUs to a system? Excuse me? Tell that to anyone who has built their own PC. Better yet, tell it to a CPU or motherboard engineer.
Also, why does he say most programs require less than 1% of a modern CPU’s power as if 1% is a small number? It’s a huge number when you multiply it by the number of processes running on your system. With nothing but terminal and a few tray items I have 172 processes on my Windows 11 machine right now. Damn right they each consume less than 1% of my CPU.
Am I… missing something?
The "1%" thing is a rhetoric trick again. If he just means the process tab in the Task Manager, then this the browser I am typing in right now is using 5% of my CPU and I have a very high end CPU (AMD 7950X). So that alone disproves his argument, but he'd switch to "I didn't actually mean 1%, 5% is still a small number". It's a game of constant pivoting and goal post shifting.
Robert C Martin is a weird one tbh. Seems like a niceish dude, but is the whole thing a grift? Does he actually have any experience at all? I have no idea and it's hard to tell, but something just doesn't pass the sniff test for me. (don't sue me uncle bob).
"Clean Code" is more bad than good. Agile is worst. Those two ideas have probably done more damage to the enterprise software world than...well I dunno. They are just fundamentally shit. Anyone who has been in a SCRUM meeting or debugged 14 thousand levels of inherited SOLID code will know what I mean.
Bob is too far in. This is his job. He will never admit that "Clean Code" has short comings or makes assumptions that just breakdown under the lightest reasoning. That's fine. I'm more disappointed by supposed experts who buy into this crap. A lot of these people should know better.
I don't know if it's a grift or not. But one thing is clear: Martin's reputation is on the line, so he would defend his Clean Code to the end.
And it's very easy for him to do that. All he has to do is to look like he actually believes his own words during presentations or talks. All politicians use the same approach.
The fact that he was pushed into debates with Casey actually weakened his position. So, he's going to great lengths to try to look like a winner.
I wouldn't call him nice, in a political sense. He thinks the cops having more power is a good idea among other odious views. He's like the soft-spoken but racist old uncle that people put up with at Thanksgiving dinner for the sense of family. A huge swathe of "terminally online" Twitter devs have him blocked for the non-programming shit he says.
@@etodemerzel2627 But he wasn't pushed into a debate though. He willingly stepped into it. Why would he do that if he knew he was of full of shit?
@@temper8281 I may be wrong about it. It was my impression from Twitter that he stepped in because people were asking for it.
SCRUM != agile (edit: not to mention, people usually don't even do Scrum right, but bolt on even more bad stuff/meetings)
e.g. in terms of game development, having the gameplay designer and a gameplay programmer in the same room is basically agile
I'm working on a couple of projects right now that have been implemented using "clean" code techniques. Not only do they have very poor performance when they run but I find them to be way harder to extend or maintain as the code seems to be spread around everywhere. The worst part is that debugging can be a real nightmare because some parts of the application feel like they're running as a side-effect of something else running, rather than as a deliberate effect or action of the thing that you are running. It leads to jumping around in the code way too much.
It's all becoming very dogmatic but not meaningfully better.
I'm not the best programmer out there, heck, i'm probably below average, but..
The way I write is usually to strike a compromise between principles and convenience. Principles are great in general, but when it becomes annoying and messy to follow a design "principle", I disregard it and use a different method.
Which clean code techniques? Promoting mutability isn't part of clean code, maybe, you are confusing class obsessed or highly overengineered programming with clean code.
He's never going to concede any points. If he does that, he'll lose book sales.
When i see discussions about clean code i often think about a certain ecological principle. The effectiveness of a strategy is often dependent on the environment and changes over time.
That's green code my dude. Scream code on the hand is when you get assigned to do javascript on a project where previous developers left right when the thing exploded to their faces. And that explosion happened at the moment they started writing javascript.
There are modern ways to do both dynamic and static polymorphism in ways which I would subjectively consider "clean"
Static: most prog langs offer ADL/ overloading or even better, generics. Operator overloading, for example, is static polymorphism in nearly ever language
For dynamic, rust has enum types and C++ has std::variant as a type-safer union.
Inheritance is just awful though. It might make the code "clean", but it makes it un"clear" IMO. That dependency inversion sounds great but is a pain to try to wrap your brain around in a foreign code base
Isn't "dependency inversion" just another way of saying "two modules should communicate/interact via interfaces, not via classes"?
@SterileNeutrino yes, but that definition misses the difference between doing that at compile time via generics (good, no runtime cost) vs. doing that at runtime via indirection and vtables (bad, runtime cost that's often not necessary in a closed set of possible types where variant or enum types would be faster)
The MAIN purpose of dependency inversion, (37:48) as I have understood it, is just so that you can easily write unit tests and mock "dependencies" aka external web services and databases. The way Mr Martin talks about is a very round about way in my opinion.
The are tradeoffs of course but if the company values unit tests and test coverage then dependency inversion is kind of required (as I understand it).
I understood what the concept is meant to be but he was all over the place in this specific discussion. It was really annoying.
@@GingerGames Totally agree, but I find it weird that he would not mention the point of allowing mocking of dependencies in unit tests as the main purpose behind dependency inversion. Instead he talks about it with, as you said: "his own made up language and terms"...
I would say it also makes refactoring much easier, or even possible. If modules only export interfaces instead of classes, the implementation of a module A can change at any time (including for bug fixes, extensions and whatever else you can imagine) but will be limited to module A. You don't even need to recompile or in the worst case review the whole system. Even better, you can rip-replace functionality while the system is running (within limits). Runtime cost is a table lookup on each call of course.
@@SterileNeutrino Fair enough, but I feel like this is not how it is approached, rather its like "always follow the dependency inversion principle" without concidering the tradeoffs, like performance and cluttering the code with base-classes/interfaces.
Many applications are never gonna make use of "replacing functionality during runtime" for example.
So the strongest argument by far is the unit test mocking in my opinion, not the other stuff. Do you require unit tests where you can mock external dependencies. then yes, pay the price of inverting your dependencies.
@@SterileNeutrino Have you ever tried to abstract your sql database? In c# there is this thing called IQueriable it's an interface and no one has managed to implement it, EF for example has two ways to solve the issue not implement a functionality or add new methods for different providers that are db specific. Tell me how do you refractor a query that isn't supported by a database?
1st time viewer here. I've never heard of your programming language, but I might have to check it out. I mostly write in rust, python, and c++
We live in a world where there is need for both clean and performant code. If you're working in a code base where performance isn't an issue or only gets you minimal gains, opt for clean code. If you're working in a code base where performance is vital to the product, do whatever it takes to get that performance. I don't understand how this is even a debate.
It feels very wasteful to consider any application a usecase where performance is not an issue. At the very least it just a waste of electricity.
Maybe scripts are an exception: if the code runs once a day, you don’t deploy a server for it nor is it published for users.
But so much of the code that is needlessly slow runs on thousand cloned servers, is executed by millions of daily users, or is constantly running on the background of every computer in some company.
So I feel like it is at least an environmental issue: I don’t mean like there is a moral responsibility to only write C or C++, or do something crazy like using assembly functions in your code. Like Casey showed, much of performance comes from small choices, that are still perfectly readable. And it is true regardless of language.
@@catcatcatcatcatcatcatcatcatca I may have explained poorly. If code is written cleanly but causes your application to become slow, absolutely look at optimisations. But if you're adding new features to a product that doesn't necessarily need to squeeze every ounce of performance, you're probably costing your business money in trying to over engineer a solution to a problem that really isn't all that important.
I think there's a place for both approaches, it depends on what you're building and what the actual impact on speed. If you're writing cleaner code and the performance hit isn't noticeable, I'd always start with that approach as you'll be able to work more quickly because you don't have to keep re learning horrible code.
I just think the whole argument is pointless because there are valid arguments for both. Basically just use the best tool for the job, but where you can, keep the code base clean so you, and others, can come back and understand what the coffee is doing.
Thank you Robin, that's exactly what I think about this futile discussion.
@@robinlloyd1121 but clean code isnt actually clean its just unnecessarily verbose and pessimistic. thats why oop is bad and doesnt work in the real world and nobody can truly conform to it without breaking rules and having alot of friction. and even if initially performance isnt a concern its going to be as it grows so its best to code sanely from day 1 and not have to refactor a lot later or make it harder to understand how it works.
@@lilyscarlet2584 I'm saying it there is room for both because it depends on what you're working on. If you maintain a clean code base, it's going to be much easier and quicker to make changes as it's easier for other developers to read, so in some cases you may want to sacrifice a slight bit of performance to enable better productivity. Of course if you're working on a project where peak performance is absolutely critical, it's best to do the opposite so you're getting as much performance out of the code, but you're then sacrificing productivity as it's likely less readable. This is why I'm saying it's weird that it's even a debate because it really depends on the situation you're in as a developer or team.
Also I don't buy that performance becomes an issue down the line either. If you have the correct tooling, you can keep a team honest with performance by adding pipelines that check for performance metrics. We have such tools at my work and we're able to maintain a clean code base whilst maintaining realistic performance standards.
"I, of course, agree completely that there may be many circumstances where you would like to write a lot of code in terms of some series of operations like "open", "read", "close", and not care exactly what is being opened, read, or closed."
He just gave up the entire game.
Casey's entire idea in this performance aware series is that you should always know what is being opened, read, or closed. The entire position he is taking here is that abstraction of this form is BAD because when the programmer gives up being able to inspect what is being opened, read, or closed, they can no longer find ways to optimize how they open, read, close etc.
exactly, but this C-like cult programmers didn't catch it. Also the guy in the video cleary shows he does not understand what dependencies and inversion of control are.
Should we start calling going for performance “Green Code”?
Optimizing for the least amount of CO2-equivalents for the code that is to be run.
I think notepad++ went that way actually lol. Like most things related to manufacturing though it's the cost of requiring more hardware to do the same task expressed in such a bloated way that's probably the bigger waste rather than the easy to measure electricity spent running the program after the fact. All the wasted college education and man hours working on "OOP for everything" software that's such a clusterfuck to maintain and generally even requiring hardware manufacturers to cater to their bloated approach and thus make manufacturing of hardware even more expensive. We are getting insane indirection compensation these days, and i hear they are looking to make PC's have a 32 byte cacheline rather than stick to the 64 byte one we have now. I hate being that guy but this seems to just be catering to normies that don't have the desire to actually problem solve but would rather shove half baked shit out of the door faster regardless the long term consequences of even maintaining that steaming pile of crap.
I once looked for the source of the error in a java ee project and i couldn't find the problem in that code for a week due to the complexity of too many classes and XML configuration files.
Wholeheartedly agreed. Since we switched to a procedural-style programming, our experience has been much better. Simpler and more straight to the point code, way easier to follow and reason about, cleaner data structures, and no artificial bloat just to support some OOP principles that mostly don't bring much of anything in practice.
It is interesting that Martin did not understand that Casey literally made an example for the union / enum style being better both when functions change often AND types change often.
I guess it is fine however that Marting tries to agree it is "clean" somewhat what Casey is doing. He is not referring to "clean code of Martin" but just use the term "clean' here as english dictionaries put it. I think the whole point of this coming up is "okay we can do clean and readable code without doing that kind of Martin style that sacrafices performance and in some ways also productivity".
I really try to design without inheritance and vtable polymorphism and it many times becomes awsome codes to take care of.
You made a mistake at 19:30, Martin wrote "BIG badly named functions". He did not drop the size scope from the prior half of the statement (smaller well named functions).
Just curios, did you read the clean code books? You are very patronizing but don't even take the time to understand what he is trying to acomplish.
I'm a Casey fanboy and I didn't really think Bob was being malicious here.
To me it felt more like he was genuinely having fun at the beginning of the conversation but gradually became frustrated. A pattern you see over and over again is that he *thinks* they're both on the same wavelength only for Casey to brutally tear into his argument over and over again, I think I'd get frustrated too!
@The Adjudicator Please enlighten us, and share the "research". I really want to switch to clean code. Finally someone can give us some facts with data and metrics. Casey right now.
@The Adjudicator Stop pivoting. Where's the research?
@@etodemerzel2627 I can't see their comments, what was said?
@@LinucNerd RUclips comments are becoming shit.
I can't see them either.
Its OK to hide stuff you think is spam, but let me see it if i want to...
@@gaurangshukla8235 That's the thing most of what we have is all anecdotal but the one thing is that Casey seems to likely have tried OO, and a bunch of other approaches not even just functional, and got a better feel for how to do things. I could be wrong but uncle bob doesn't strike me as someone that's ever tried anything aside functional or OO. But aside all that it'd be really nice to actually collectively come up with semi real life examples, i've definitely seen that most things i've looked at so far haven't benefited from OO practices however it would be interesting to throw up a gauntlet of sorts where we can all chip in our own example code.
I still don't understand why Mr. Martin trademarked coding common senses. And some of his takes are just plain stupid.
Wow. I read the qa when the first document finished and thought that that was it. Oh how glad I am there was more. absolutely love it how Uncle Bob couldn't even hold his ground against sensical code even in the canonical case point picked to favour inheritance.
I first was introduced clean code by other fellow traveler professional programmers like myself. And they were starting to get rigid and awfully judgemental of many things when it made no sense. Felt like they were all part of a person cult . Then I thought what the heck and I read about clean code. I felt a lot of the things in it were like no-brainers. The more I had dug into it. I started asking myself was all that coming out of this person by building projects of different team sizes or scales. Cause I felt there was a disconnect. Seems to me Martin is a Theoretician first and foremost. And after the advent of his work. I see that there is an appeal to authority. and a high degree of justification to align highly subjective points of views. Thanks for making this video. It makes soo much sense.
real VIPs watch in 360
Everyone called him Uncle Bob, because, well, Bob is your Uncle...
Clean code is:
- Reusable functions
- Clear division to files by purpose/theme
- Some comments explaining what is does
Clean code is NOT:
- Desperately trying to keep file sizes at a mininum
- Dividing everything into 4 different places
- One liners
- Pathological fear of using if-else if-else statements
- Very fancy "hacks" to milk out 0.00001 ms more performance when you're making a simple website
Congrats! Now you have your own definition of Clean Code.
@@MikhailBorisovTheOne they could share it with casey if he didnt block all comments on his youtube channel.
Comments should be minimal, comments have a tendency not to be maintained well. So they may be obsolete at some point when the code changes. Ideally code should be its own comment. Only use comments if the code does something unusual.
There is no proof that "clean code" is more productive. When you look at the lines of code, certainly, "clean code" takes vast amounts more code than just writing the code that needs to be written. I wouldn't expect for that to result in saving developer time.
As we also have measured, the best predictor of bugs is the number of lines of code that you write (bugs per line is remarkably consistent across every language and every paradigm), so it makes sense to me that "clean code" actually results in more bugs above just writing the code you need to, which costs more for developer time.
Uncle Bob has zero proof for this claim, and people need to start calling him on it.
Ugh I really hate the snarky response to the question how do you measure code readability. By reading it? Really? In that case, readable code is code with zero comments (yes, really, programmers tend to be terrible at getting their point across in English, but programming languages are much more strict and well defined, so it's much easier to just read their code rather than their descriptions of their code), no templates, no operator overloads, no exceptions, no inheritance, no constructors/destructors and definitely no splitting logical, coherent code blocks into smaller functions, even if the original block is a thousand lines long. All of these things make code extremely difficult to read. I wonder if Mr Bob would agree with his own answer in that light?
I watched Mr. Martin's lecture once. I did not finish it. It felt like he was giving cult rules rather than explaining his reasoning.
But I'm trying to understand, what does the opposition of uncle Bob try to achieve? Is the goal to explain that clean code is not worth pursuing? That's a completely wrong goal IMO. Yes, there might be cases when you want squeeze max performance, so you inline several functions, compact data etc. As a result, the code quality decreases for a very specific reason: to have performance benefits. This process is called optimization. But remember that in a nested for loop, 95% of time is spent executing 5% of code. Why wouldn't you want to tidy the other 95% of code, for which the performance does not matter much, but the amount of human effort required to maintain the code matters a lot?
Or is the goal to criticize uncle Bob specifically. As for uncle Bob's arguments, some concrete advice might be outdated or debatable, there is a certain degree of subjectivity in this area after all, but we need to look at the bigger message he's trying to say. And the bigger messsage is that software engineers should be responsible in writing readable and maintainable software (and learn how to do that). Sadly, in my professional experience, many colleagues bear little responsibility for how they build software...
I ready the articles and it was a great discussion between two great engineers with differing viewpoints. What I got out of this video is, that you really don't like Bob Martin. I apologise if this is not the case.
I've worked with code bases that I would consider as "spaghetti code". We spent days just trying to add simple features. But it did run fast. In the end we junked and re-wrote it. The new solution ran 2% slower, but we could add new features in hours not days. With a bit of analysis and benchmarking it ended up 10% faster, but clean. I would say that most senior level engineers can write performant, clean code (easy to maintain) straight out of the gate. There really is no excuse for unclean code. As someone once said, "pretend that the person who is going to maintain your code has an axe and knows where you live" :) I see clean code as code that lends itself to easy modification by many different people over a long period of time and that can remain clean.
The video is very anti Clean Code oriented. Too bad that people arguing and tries to take sides when the reality is always a balance. Sometimes, not following the Clean Code thing doesn't make it hard to read. Sometimes it does. And there will never be a metric for that. Because, in the end, good code is an art.
So if Martin would say "if you follow these principles, you'll get this advantages" and Casey would say "if don't follow them, you can't get these advantages" everyone would be happy, not fighting and not making hour video long to fight each other.
"programmer performance, and not algorithmic performance". Geez. Such a false dichotomy.
Widget V1 is ugly but it works.
For V2 If it means I can squeeze some performance you bet your bum I'm gonna do inline assembly and bit shifting tricks.
Performance saves millions, specially in server costs and user experience.
Lag can kill ppl.
Much as i've been around here bitching in the comments, honestly... I mean yes it's a false dichotomy but if you manage to use the correct programming pattern that at least mostly does the job right, optimizing won't be as much a pain in the arse, not enough of us are learning data oriented design to get a healthy dose of variety in our mindsets. And while i can't say DOD is perfect it does propose a lot of interesting points that don't seem entirely false. Slapping tons of micro ops without wrangling things properly of course are going to hurt but decent profiling, being aware that data layouts do matter, realizing that profilers can't pick up everything, just trying to actually think ahead does wonders and enables you to more easily do this stuff. And yes a person can totally think ahead for a project going multiple months to multiple years i don't care what demands are made later on, there is value in thinking ahead more than "do X rules all the time and expect them to always work". The choice usually isn't "programmer cycles or runtime cycles" that expectation that there's a flat natural rivalry between these things is absolutely insane.
@@duncanshania yes.
I think a hidden problem here is that CC probably doesn't actually save cycles of any type.
@@duncanshania What's the best web site or book for that?
Yep.
1. Make it work
2. Make it fast/small
3. Make it pretty
@@strayling1 I like the brevity. What's the history of that wrt maintenance and changes due to "improvements", additions, or other things?
"especially your seniors" just reinforces the idea that most modern programming practices, such as "clean code" aren't even about making things easier/better for programmers (at the cost of performance) - it's about making projects easier to manage and quantify for managers, at the cost of both performance (on the hardware) and understandability (for other programmers).
I don't take it that way at all. The seniors are the ones managing the changes of the juniors, fielding their questions, fixing their mistakes, etc. Subjective as it may be, many people see far less difficulty for juniors in code bases that tend toward the Clean Code ideas.
41:50 But why would I make files polymorphic by default? Just because files might work differently on different operating systems?
In this case I would just use compiler flags to use different implementations. Polymorphism sounds stupid here. I won't be able to use the Windows implementation on Linux anyway.
And for streams and sockets or whatever, it might be useful to have different abstractions. But these abstractions should come second. We shouldn't try to force different types into a single interface. There are some things, which might only apply to one of these subtypes.
If there are similarities, a common interface might be implemented as an afterthought, when you need it.
This is a pretty good video, but you perhaps ascribe too often a malicious rationale to Martin's answers. "Here he uses a trick" "Here he intentionally changes the question." Your video does better when it just takes things at the surface level of the text. Just my opinion. Unasked. Feel free to throw it in the bit-bucket.
Loved the video gb! Thanks for putting it out there.
I had to turn up the volume way up though, did anyone else have the same issue?
"Prefer polymorphism to if/else or switch/case" is not an accurate summary of the Clean Code view on this topic at all.
Bob Martin has ample books and video courses available where his analysis about if/else and switch/case are explained at length. Grabbing some shitty github markdown summary from a third party poorly summarizing Clean Code and claiming it's an accurate summary of Bob Martin's curriculum is completely absurd and offensively poor scholarship.
Bob Martin is not responsible for how "wojteklu" summarized Clean Code for people too lazy to actually read the book. These kinds of summaries are for people who do not want to understand at all, who want quick soundbites and "rules" that have been stripped of all meaning and context and turned into absurdities.
The sections that are being referred to do not teach some absurd rule to be religiously applied, rather they demonstrate what goes wrong if you use if/else and switch/case badly, introducing if/else all over the place in the code so that you end up with poorly organized, spaghetti code which constantly has to worry about serving multiple different business use cases. You end up with code that is extremely hard to read to figure out what branches of code apply to different cases, and having to go all over the place and figure out what special condition applies in this case or that case.
"Prefer polymorphism to if/else switch/case" is simply a code smell/heuristic, it is not a "rule" at all. Bob Martin makes a clear point in the book that Switch statements ARE appropriate for precisely the kind of example Casey gave: all Casey did was a tagged union over a known set of types, and Bob Martin clearly states that in such a case a switch is more appropriate, specifically and I quote: "in the parts of the system where adding new functions is more likely than adding new types".
Code Smells are not rules, they are simply very common patterns that if you see littered all over the place suggest there may be a better approach to consider. Casey's code wasn't littered in switch statements, it had one clear switch statement which is precisely the rule Bob Martin recommends. So completely contrary to Casey's claim that he was "violating the central tenet of Clean Code" and that "Clean Code lectures would tell you to 'never ever do this'", reading directly from the Clean Code book we can see clearly that *the literal book of the title tells you to do what Casey is suggesting*.
None of this is hard, there's literally four paragraphs in the heuristics section about this and literally every single one of them shows that you and Casey are completely wrong about what's actually being taught.
Casey even remarks in his post that he's confused about the "rule" because, obviously, if/else and switch/case are themselves techniques for achieving polymorphism! It's almost like if Casey or you had bothered to actually read the book, they'd have realized the confusion, huh? Had you done this, you'd find out 1. it isn't a rule, and 2. if/else and switch/case are perfectly valid ways to achieve polymorphic code! Bob Martin simply recommends that for any given selection, you keep the switch statement in one clear place, encapsulate the switch into a polymorphic unit of code, be that an object or a plain function, or some other kind of unit of code, so that the switch statements do not proliferate everywhere as they are wont to do if you don't apply the grace and restraint that Casey applied and all experienced coders provide, by following the ACTUAL recommendations from Clean Code (whether you got them from the book, or from hard-earned experience), not the fake summaries off random github gists.
The solution presented is not simply to "use polymorphism", the solution is to think clearly about the decision points and where to put them. Dynamic dispatch is a convenient way to move up to a higher level of abstraction and think about where to put the switch, it is mostly a pedagogical tool. The actual point is not the polymorphism at all nor the way we achieve the polymorphism, rather the point is to write understandable code. And Casey did that in his example: he retained all the actual design principles in the structure of Bob Martin's example, switching from a vtable to a case statement or a precomputed table didn't actually change the real design principles at work in the example at all.
great video, but I suggest increasing the audio volume a little bit, otherwise your videos are very difficult to watch on mobile
It's almost like going to extremes on nearly any idea is bad.
I went and read the whole discussion between Casey and Uncle Bob. A truly fascinating read and I implore viewers to read through it themselves.
25:03 I actually thought this framing of problem time scale to be quite acceptable and useful. When thinking about segments of code it's often useful to know what domain it's in to know whether to devote time to improving its performance.
What's clearly misrepresented here is the distribution of code that falls into the categories, and this will obviously depend on the domain of the problem, but in my experience, most code falls into the nanoseconds category on modern machines, with some larger operations being in the milliseconds (and these will usually contain many segments in the shorter time-scale categories). Any ops that take seconds or longer will ALWAYS be either the whole point of the program, or a large part of it.
Obviously if you look at modern software it's easy to see why one's perception of these categories could be skewed. There aren't a lot of examples out there that demonstrate just how insanely fast modern computers are.
(Edit: Reading this last sentence back, I have to at least partially retract it. There IS a lot of software that takes advantage of the hardware quite effectively, but negativity bias makes it easy to forget that. There's enough software that wastes our time to a large-enough degree that it's easy to think computers are much slower than they are.)
Do you have a link for someone who is not in the loop of these discussions?
@@dreamforgegames4776 All of the links are in the video description. I would copy it here for you but I'm on my phone and for some reason that makes doing so prohibitively difficult 😑
@@equivocator7727 I'd recommend against sharing links in RUclips comments, because RUclips tends to silently delete such comments.
On your last point i can attest as someone making a sandbox game project, the code i've got is easily a hundred tiems more maintainable and runtime efficient than any others i've seen in this domain and most all of it's thanks to choosing a better set of abstractions for the project that actually serve a purpose rather than as mike action would put it, trying to pull something from the ether. It's a bit in the early stages and is somewhat buggy but it's trying to for now simulate 10k dumb zombie pathing like NPCs in a destructable voxel sim and seems to do so well above 60FPS, and will continue to improve as i keep fixing bugs and design issues. I can't imagine the efficiency this'll gain when i put it on a unikernel after a server specific application is made for this. The thing though is, am trying to actually describe the problem, a lot of these runtime improvements came as a consequence of trying to actually get something out there that's more maintainable and sensible. There's really no micro opts in this project as of the time of writing this. That premature optimization is evil perspective OOP centric programmers tend to use is honestly complete bullshit and not accounting for the bigger picture. But you can't expect people that only stuck with one orientation and maybe a couple patterns to have any sense of what could make code complex or cleaner let alone efficient. You need experience and need to explore other ways of doing the same things and try to remember that at the heart of the issue we are trying to solve a problem that is the raison d'etre of the software. Not trying to fullfill some convention when it doesn't serve this purpose.
his idea of clean code includes mixing languages in a project?
34:50 This basically only applies to Java.
And I don't think, that's even true. At least I'm pretty sure, it doesn't have such a high cost for other programming languages, at least if the compiler is able to cache some functions.
If you change the case of a switch statement, you would only have to recompile that single function, which does the switch.
Why would you need to recompile anything else?
Maybe you added some parameter to a struct, but this would only require you to recompile all functions, which depend on this struct.
In case of Java, the compiler is so fast that it's acceptable to recompile everything all the time. For example, Maven used to have two compilation modes: simple, when it recompiled only modified files, but which could cause miscompilation, and incremental, which tracked dependencies between files and recompiled exactly what was needed to give correct results. It then turned out that tracking dependencies is slower than just recompiling everything all the time, so the incremental compilation in Maven now means "recompile everything".
Does dirty(I intentionally didn't call it bad) code results in bad software? No, not necessary. Is it working, doing it job, fulfilling its' purpose? Yes! Is it easy to maintain, extend, understand when it is needed? Probably not.
If you have ever lived alone for a longer period of time you know that there is no such thing as clean. Cleanliness is the measure of dirt in your house. Decrease it enough and it looks clean. Same thing with code. You will never reach 100% clean code, but the more is the better.
The whole question of switch VS subtyping is a well known problem called "the expression problem"
exactly, my point is that Casey is not actually against Clean Code, but he just does not like OOP. When you need an Enum to identify your type, you are doing something awful in your OOP design.
I think Uncle Bob should just retire. From his comments I have the impression he turned from senior to senile.
He's far from senile, and this is how he's always been. He's effectively a snake oil salesman. His product is himself.
I know of one case against readable variable names, which is for URL and HTML form parameters. Readable variable names and path names use more characters and inflate the size of HTTP headers and POST content. There is a real world cost in dollars caused by consuming additional network bandwidth when millions of web requests are performed.
I don't have any issue with clean code as a set of heuristics. I have an issue with developers treating them as immutable laws. Clean code tenets are quoted like religious proverbs that cannot be broken. Context means nothing. Scope means nothing. Performance reviews resemble an argument between a Catholic priest and a Protestant minister quoting bible verses which don't actually resolve who's correct.
My set of heuristics are intentionally over simplified. Don't nit pick. Focus on what's important. Does the code work? Would an average developer understand it? No: refactor. Yes: check it in.
Try to understand the developer's strategy. Require they explain the code if it looks disagreeable. The point is to get shit done. Don't battle over implementation decisions that are often arbitrary.
The video you are referencing has popped up in my feed too, and seemed trollish, seemed like something off, either intentionally off, or templeOS -- ah, he made sense while talking about opcodes and stuff. I felt trolled by that person I wanted to never hear about again.
Yet, now your video pops into my PMs, from someone who got caught by the clean code blabla video, and PMed me to ask me where I stand. So I see now that unfortunately, it got more than its fair share of attention. Anyway, thanks for your clean video. Liked.
History: I grew up doing assembly, and nowadays corporate codebases that are tens of thousands of steaming piles of code. So I may know a thing or two about both performance and maintainability. They are tools, and I don't like evangelists from either side.
Wait a sec, you mean mostly the performance centric programmers as in the ones that try to micro literally everything? There's a difference between doing that and writing performant code while writing maintainable code without really losing any time. And i've seen like 1 or 2 cases OOP did me a bit of good but it's very small examples compared to the god knows how many lines i've written/read over the decade. And totally you can go extremely one way or another. The majority of the insanity at least that i've seen is in the court of folks assuming to write actually clean code is to neglect performance and doing that whole "premature optimization is a sin" meme.
@@duncanshania sorry for being late, for some reason, I got no notification that I got a response.
Uhm, yeah, as you may imagine, as a veteran programmer myself, beginning in the assembly era, and having written both greenfield code and maintenance code to some decades old legacy projects, I have *a lot* to say. I just don't feel entirely comfortable writing more than a few hints about it here.
Last time I looked at obsessive code was today: Hungarian notation all over the place, while the EEPROM's size was stored in a signed int that never ever went below zero (not even as a status code).
That being sad, sure, don't write the >>airquotes
@@varadinagypal This i can get behind. If you write code that actually solves the problem without pointless additional complexity that honestly seems to actually optimize better than for example using OOP for everything, so my reason for not using it for literally everything is first and foremost for readability, yet the side effect is that data locality is easier for me to manage now on an instant subconscious level, that's where most of your runtime benefit would even come from. But after the fact actually doing micro opts down the road when you find a sufficiently good case for it actually becomes much easier and more potentially useful. It's a matter of being honest about what the computer is doing roughly. And being honest about what you're actually trying to accomplish. Adding fluff for the sake of adhering to any convention regardless the context of the problem is how we are in such a hell hole to my eyes. These arguments about software runtimes in context of OOP is therefore honestly too 1D to my mind for the vast majority of the conversations.
C is NOT harder to develop with. Conversely, C++ is NOT easier. If anything, the additional typing of all the syntactical garbage of C++, combined with the fact the source files are typically larger than the equivalent C code, means C++ actually takes longer to develop.
On top of that, C++ is much harder to parse when read by a human, so increases the time to understand, especially when it doesn't work as expected.
I remember my first exposure to clean code and being horrified at the conclusions. For example, long vs short functions misses the point entirely. When you write code, you're telling a story and gviing instrucitoins to take an action. If someone was telling you a story and giving you instructions would you want to sit go to one house on your street and listen to the narrative, or would you want to go from house to house getting a line at each? When the group of actions can be described in a summary word or phrase, you have something that naturally forms a function - I've never been one to tell a story in 3 lines or less. Unfortunately software design deals in fashions and cults at least as much as it does in science, and such common sense ideas go out the window for software development movements.
Noone ever stated that OOP is performant. Arguing against OOP principles is like arguing against fire doors. Sure, they are expensive and less comfortable to use but over a certain building size they are absolutely necessary to minimize damage in case of an emergency.
The example code in Casey's video was kept this simple for demonstration purposes but otherwise it is a textbook example where virtual function calls have a huge overhead. It would be very interesting to measure the overhead of a virtual function call if the function does more than a float multiplication... I would also love to see how Casey's code would look like after two years if they extended the system with 20-50 new shape types, some of them developed in US, some in Germany, some in India...
And yes, I also find Clean Code ridiculous.
> Noone ever stated that OOP is performant.
Mr Martin does quite often on Twitter. The person I am commentating on in this video.
Virtual function calls are bad enough but the root of the issue i find in my domain is that using excessive abstractions which contribute to nothing for the problem the software is actually trying to solve, screws over the runtime in multiple ways. In such a clusterfuck that for example 7 days to die and other such sandbox titles can't do a hundredth what my opensourced project can do in runtime, let alone in adding new mechanics considering how hellish their code is to maintain. I find performance typically goes with maintainability but to get something maintainable you need to actually solve the problem without adding pointless steps between, and how to do this am not entirely sure how to express concisely yet to be honest. Of course runtime importance is going to vary a lot from project to project but i find for all the projects i do which end up lasting at least multiple months, OOP seems to diminish maintainability the vast majority of the time. Though it might not be bad for UI though UI is something i almost never get into. Am not fully sure on that yet. The approach used should depend on context. But to be more specific about the virtual function calls. Perhaps always but typically when you use them you're discouraging the possibility of batch processing, and the more you discourage this the less optimization potential you'd have as a result. Least it seems this way most of the time. When it comes to runtime data locality comes first, then culling needless indirection, then avoiding unnecessary branching (can be done via existence based processing). And all of this coincides generally with actually solving the problem. I find doing micro opts after this is just icing on the cake not actually the meat of runtime improvement.
I am very surprised Uncle Bob actually knows how to use Git. I've worked with his devout followers in various companies and most of them wrote shitty littly Java applets or whatever in 2001 and since then have been pushing sticky papers and Jira issues. Bob hasn't written anything of any importance and does not develop anything in open source mode, so all his bullshit is unverifiable. I would much rather take advice on programming from thousands of people on Github who wrangle dozen different languages in dozens of public projects that are visible commit-per-commit than some boomer that allegedly wrote Java in a corporation twenty years ago.
The entire 'discussion' is unbelievable pie of bullshit that Casey had to endure.
8:30 My experience has been that splitting into multiple files starts to be worth it from an IDE performance perspective around 10k lines, but it's worth it from a team collaboration perspective at a somewhat smaller scale than that. The problem is that if you have a few large files and a big team, you're going to end up doing a lot of merging which your version control may not always get right and it makes it harder to cherrypick other people's work into your own branch. If functionality is split up among multiple files - or even multiple functions/classes, to an extent - that all becomes less of a pain point.
IMO Clean Code proponents should have pushed on *that* argument as it's pretty much universal among any team larger than about 5 people, rather than what they typically do which is their nebulous "coupling bad TDD good" line of argumentation. Not enough effort goes into explaining why people should prefer low coupling in the first place or why it helps for collab - it's the merging!
1:09:00 Isn't it two levels of indirection? One for the function pointer, one for the switch statement.
1:18:35 LMAO. I can't just glue more CPUs to an Xbox One, Bob...
The problem starts with having a language or even a grouping principle based on "files". Something is completely wrong and 70s-like.... we need to rethink that principle.
@@SterileNeutrino C *is* a '70s-era programming language :P
@@babgab I know. 😊Have you read "C Is Not a Low-level Language - Your computer is not a fast PDP-11" by David Chisnall?
@@SterileNeutrino That's actually curious and while i think there should be a better way it makes sense to keep the concept of compilation units to some degree, though the way C/C++ didn't standardize linking in any sufficient way to the point we are stuck in cmake hell isn't very fun. But aside that. Being able to manually dictate how many compilation units i produce and how gives me control over how the code recompiles and it's proven very useful. Even though C++ is a slow to compile language i've managed to make custom games and engines that entirely compile in 6 or 11 seconds, and most of it's the engine, but when the engine is compiled, it's compiled, it's like you want this balance where you don't have too many compilation units, but you want some so that when you work on something it's not going to cause a full recompilation. C# build times are awful in my book but so is most C++ libraries and programs since most people are crazy enough to make a source file for every class and have generally one class per file, that's generally how more OO centric programmers do it though that's a culture thing and less an issue with OO itself probably. For full honesty i prefer to mix header only style libraries that i develop, with some form of building that's a bit similar to a unity build, though not strictly.
29:25 - Holy Eff! LOL, ruclips.net/video/gPgm28zXNEE/видео.html is absolutely INSANE! I thought he was probably right, but slightly exaggerating. Turns out Casey was _underplaying_ how bad the CleanCode principles were!
Oh hell yeah. I just got home, grabbed dinner and saw the video recommendation and the title and just thought "It is on! This is better than soccer"
19:25 He did talk about the length. You didn't read the word "big"