@stainlesssteellemming
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.
@Tekay37
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.
@64jcl
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.
@DetectivePoofPoof
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.
@GarrethandPipa
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.
@dukereg
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" đ
@mynameistrez
Regardless of anything else, Martin not having watched Casey's entire video before their talk is WTF
@hareepjoshi
Bob's livelihood, his persona and his ego all revolve around Clean Code. He will defend it by any means possible.
@optimizt8555
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.
@steshaw6510
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!
@yugr
7:45 - Bill, do you mainly work on compiler frontends (parsing, type checking and other semantic analysis, IR generation for external compiler like LLVM) or optimizers/backends ?
@Lightstrip
Uncle Bob is a real pro at what he does, which is very good for him... Probably unfortunate for programming community.
@bitskit3476
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.
@johnterpack3940
Applying the Clean Code mindset to basically any other field shows how insane it is; "We need to design cars so that they are easier for mechanics to work on, how they perform is secondary." Code exists to solve a problem for an end user. It isn't an art project. The only priority is allowing the end user to solve their problem as quickly and easily as possible. If that requires intricate code, so be it. Programmers aren't any different from plumbers, carpenters, or factory workers in that it's literally your job to deal with the complicated bits.
@caareystore444
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.
@dorbie
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.
@grumpy_cat1337
14:56 clean code is for programer performance??? PROGRAMMER PERFORMANCE??? Man I'm butthurt, writing "clean code" takes so much more time and causes so much analysis paralysis, that's not even funny how absurd that statement is. Not to mention how hard it is to understand someone else's "clean code".
@onetruetroy
âClean Codeâ is one of those buzz phrases that really doesnât mean much. As a programmer, there are some nice ideals defined but are only doable in certain situations. Clean Code is a nice selling point to lure managers whom have poor coding skills in forcing the programmers to endure the courseware with promises of efficiency, productivity and readability. If the programmers canât do this after taking the course then obviously they arenât putting the proper skills into practice. Letâs invite Uncle Bob to see whatâs wrong. â The cleanest code Iâve written or read is when the programmers communicate and agree on practices that work best for the projects. Of course, some of the code may look dirty but it gets the job done. Yes, the documentation can sometimes have an essay on why this particular âdirty codeâ is necessary.
@kylek3822
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.
@travisthompson1679