Clean Code is SLOW But REQUIRED? | Prime Reacts
HTML-код
- Опубликовано: 28 сен 2024
- Recorded live on twitch, GET IN
/ theprimeagen
Article link: betterprogramm...
Written by: Bawenang Rukmoko Pardian Putra | / bawenang
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/dee...
First time I saw "Scrum Master" as a title I really thought it was something dirty and a 12 year old had hacked the employee directory again.
Again? lol
Now I know better. It certainly is something dirty.
They recently changed it from scrum master to agile coach where I work
Me too, totally
@@iamhardlineraka retards who haven't coded in a decade and are great at inflating delivery costs
I worked on a system at the NAIC that was written in C++ and implemented all of their polymorphism via templates rather than via inheritance. The result was wrappers inside of wrappers inside of wrappers, and the error messages were horrendous due to extensive use of nested templates. We had to pipe our gdb message through stlfilt just to figure out what types were involved whenever we had a failure. There is a happy medium between code that is inscrutable because it is monolithic spaghetti code, and code that is inscrutable because it has been atomized into a fine mist of components. Ironically the reasons why monolithic spaghetti code is hard, is actually the same reason why overly abstracted code is hard. There's too many things to keep track of in your head, the only difference being what you're tracking.
Btw did you know that you can run python in your gdb? You could have prepared a python setup for your team for gdb use for custom pretty printing this - or if that stlfilt was good-enough just auto-run it via python commands you added to gdb.
Also I am not sure when this way, because did static polymorphism like that (maybe an other architecture though) and did not have this issue.
@@u9vata at the time (2003ish) I'd never heard of Python.
I love that I haven't googled stlfilt and I'm confident in what that tool does
@@lerubikscubetherubikscube2813 :)
Well there is a difference, the highly abstracted code can be accessed at multiple levels and can be modified at multiple levels ignoring the finer (or higher level) details while the monolithic ..well it is just one big mess and you are forced to understand it all. I always think it is funny that developers are fine in using the 20 or so level of abstraction CPUs - OSs - programming language and libraries provides but then they go crazy if you add another 2 or 3 layers on top of that. Maybe the problem is not the abstraction itself but the quality and the experience you have with it. In the end complex behavior will require abstraction whether you like it or not. And good abstraction will make it easier to understand, not harder.
The fast inverse square root is self contained in its own lil function so it’s pretty clean™️ and you don’t have to worry about the details until you have to.
Yeah that is what I was thinking, as the long the spaghetti code you are writing has a good reason to exist, as in the fast inverse square root function case, and as long as that spaghetti code doesn't intersect with other parts of the code/logic then no one should have any problems with it, Clean Code enthusiast or not.
The problem, imo, is when the spaghetti code is responsible for branching logic/decision making and routing in the app. When that is the case, no performance considerations that leads to spaghetti code should be taken in account at all, as you will pay the price ten fold later on and be forced to change it anyway
@@ahmad_alhallak It's not even spaghetti. It's straightforward, linear code, which is trivial to read and understand. What is not trivial is knowing why the answer is correct, which requires knowing how floating point types work, and how Newton's Method works.
If you do not understand the mathematics behind it, it might seem like magic, but that goes for most math. If you saw Vec2_Dot(normal, point) > 0, you could understand the code for it, but you wouldn't know what it represents.
@@AidiakapiThe dot product returns the cosine of the angle between two unit vectors. It is assumed that anyone working with dot() > 0 knows that it represents the front facing side. The problem is that there should be a comment explaining the behavior for people _not_ familiar with it:
* Output ranges between [-1 … +1]
* < 0 back facing
* = 0 orthogonal
* > 0 front facing
Precisely. The fast inverse square root code is self-contained and while it isn't at all obvious how it works to the uninitiated, it is clear what it is *supposed* to do. Should you experience a bug in your rendering code and you suspect it might be that function, it's trivial to replace it with a more explicit implementation for debugging purposes. Should that replacement not resolve the bug, you know that your bug is elsewhere.
This is exactly how you want code to work - as mutable. The simpler your code, the less restrictions you have to changing it, and changing code to sniff out a bug is a perfectly reasonable thing to do. It's just much, much harder to do with huge object hierarchies and abstractions.
A pure function.
I don't see why this guy is criticizing the quake fast inverse square root. That's about as clean as it gets. It's a pure function that uses primitive data types. There's nothing to maintain there. Sure it's hard to understand, but from a maintenance PoV, it's literally one standalone function. Nothing else you change in your codebase will alter how it works.
Yea and it's not esoteric or anything. Just applies mathematical approximation using series to compute something much faster with an acceptable error margin. I had forgotten most of my mathematics from collage after I left it but even then, the first time I saw that function I knew it was an approximation, just didn't remember how it worked... it's more a case of the programmer not knowing the theory used in the code logic rather than the code being bad (as you said, it's far from it)... never skip math day on college kids :)
I don't think the article is calling the fast inverse square root bad code, just calling it unreadable code. As argued in the article, performant over readable code should be used only in performance critical sections, like the fast inverse square root is being used in.
It's more of "if there's a bug in the system how sure can you be that it's not this piece of code?". Now after years of analysis and discussions it's pretty clear why that function works but imagine someone implementing magic like this to, for example, send the request to the server and you come to maintain it and have some error around communication with the server. The function might be doing exactly what it says and the error might be somewhere else but it'd take you ages to actually confirm that.
@@kilisinovic Not really. It's a pure function that takes a single argument that's calculating something mathematical for which there are already slower, but definitely correct, implementations for.
So you can pretty easily just toss a battery of unit tests at the thing and compare the outputs to the slower but correct function to check for any unacceptable deviations. Generate a million random floats along with a few important specific numbers like 0, 1, and so forth , feed them to both functions, compare the two, calculating the average deviation, the maximum deviation from the correct answer and an array of the top 10 worst cases. That'll give you a great idea of how accurate it is.
@@taragnor that only makes you pretty confident but not 100% confident which is the point I was trying to make. What good does it do to check edge cases for numbers when you're doing shenanigans with bits. There may be none or there may be more than few numbers out there for which the function breaks but you can never be sure unless you really understand the logic and math behind the function or you examine the function for absolutely every use case.
This article does the classic defence of Clean Code bait-and-switch where one moment they're talking about Clean Code™ and the next moment they're talking about regular run-of-the-mill clean code.
There was that one article talking about how "clean" means anything and everything nowadays. Since then, every time I think something is or isn't "clean", I catch myself thinking that and try to actually elaborate what I mean. "It's cleaner", what does that mean? Does it make the code more maintainable? Is it easier to understand, more readable? Or is it just a vague good feeling I have and I actually don't have any reason for it to be cleaner, and it comes down to subjective personal preferences? Usually it's the former, but the rare occasions where it's the latter, I'm thankful that I got myself to think this way. Though now whenever someone says "it's cleaner" I get infuriated because it means nothing.
@@Speykious yeah 'clean' is the least helpful adjective to describe code. Luckily, we are adjective people, professionally per-disposed to actually meaningful descriptions. Or at least we should be. I dunno what lazy shithead thought 'clean' was helpful. I am guessing its a borrow from gym bros and their 'clean eating' crap.
@@Speykious I prefer the term "idiomatic".
@@protox4 *idiotic
Sorry, I couldn't help myself.
I think I have a very low tolerance for file length. Most files I want under 200 lines
Over the years, people have talked about Clean Code for more hours than anyone has actually written Clean Code
🤣🤣🤣
By Clean Code, you mean TDD, of course.
I think what we really need is clear code instead.
@@ericbwertz
So funny because we love the "idea" of it, but implementing is another matter entirely. I would say much of that is chalked up to the fact that just getting things working and making it efficient is far more prioritized over writing elegantly clean code and refactoring in general, some places rush you and don't even have the time to write tests before the code.
Clean code was a GOAL. Clean Code (capital) is the religion. Not in any way different from the "Manifesto for Agile Software Development" goals vs Agile. It's always a process from where you take something that has good intentions and turn it into a clusterfsck of dogmas and rituals and ceremonies. Some more cynical people might say that it happens because you can't capitalize good intentions, but you sure can turn "the clusterfsck" into a set of books, courses, talks, etc...
Maybe what you need is just an "utilitarian" version of it all. Pragmatic CC, Pragmatic Agile, etc... The pragmatic part being "does it make sense?", "do we need it?", "have we gone too far of the deep end?", etc...
At my place we have a running joke about a certain component that we refer to as "the best hammer ever". It can hammer in any nail under any conditions. Only about 15% of it's potential has ever been needed/used. Nobody truly greps to the full extent how it works. As a testament to the skill of the creator, it's rock solid and never fails. And thank god, because everyone that ever went through it in debug had to resort to some alcohol fueled "therapy" after. We just marked it DontTouchJustWorksTM because it does, and we always "Step through" never "Step into" ;)
If the code is hard to understand and maintain, then it's not, by definition, a clean code.
People don't even understand what a Cartesian product is... So you had a product with something like 25 customizable items (color, texture, etc.) and each item had between 10 and 50 options. Some options are not compatible. For example, you cannot get the pink color with the wood texture. There was a function to select the first viable combination. Said function was stupid and would compute a large part of the Cartesian product before finishing. I estimated that it would complete after about 150 years... I extracted the responsibility of computing the Cartesian product in a separate function (and optimized it to discard non-viable combinations before computing the whole combination). In that new function, I used the lexical field of a Cartesian product, as this function sole responsibility was computing the Cartesian product... The developer that owned the module asked me to rename all variables to match the business domain, because he didn't understand what a Cartesian product was. So I cannot imagine the average developer to properly understand the abstractions from the GoF...
too much padding there isn't much meat in the article.
one aspect of the constant striving for perfect, clean code that gets overlooked is the impact on developer morale. especially when you know that when you open a PR it's just going to get trashed by someone who gets a high off making others write overengineered code. I see a lot of junior engineers lose so much confidence and their performance slows to a halt because of practices like this
This is a very good point. I find it very draining to have to respond to or follow the requests of my bureaucracy-loving colleagues.
Yes any senior devs reading this need to realise that if they want to keep their staff they should allow others as much freedom as possible because otherwise you will take away the biggest joy of programming and make people resentful
18:21 "Parts of apps that need of performance" - Casey also debunked the whole "you just need to optimize the hot spots" argument. You can only do so much without completely refactoring or even rewriting the whole application.
3:18, you (23:54) and Casey said something that I already knew: wait the need before abstracting. This is the right way to design: focused on the practical needs. And that means building abstractions for defensive proposes too - before somebody starts to advocate FP.
3:35, 1 of the basic optimizations made by the machine is to inline f()s. The only concern is about reaching a limit, after which it won't inline or starts extra calculations about it - but 1 can set it. The actual problem about helper f()s is the options for calling them by mistake, or to feel the need to memorize them, as options, when thinking about the whole thing. To avoid this extra stress, a class to hide them can help. But this starts to require more boilerplate. The best solution is writing lambdas (within the f(), of course), if those blocks are called more than once. Otherwise, I keep them inside the f(), as explicit code, if they only make sense there.
5:03, if 2 apps have a difference of ms for each action, people will feel better with the faster 1. So, it's not just for speed-critical projects: even the common ones can benefit. Meta said that _"people feel more engaged when the app is faster"_ (probably about ms and above).
As a Pastafarian, I find all this discussion of Clean Code very upsetting. All of my code is spaghetti code.
good points about following the team's practices. it was hard for me at first but i learned to slow down and see the reasons for things in the code that made no sense to me at first. the best thing is to read a lot more code than you write, and put yourself in the minds of the people who came before you
Clean Code is Taylorism (the practices that lead to factory productivity) for software. For small teams or companies following service design with lots of small teams collaborating, it doesn't make *any* sense, just as it doesn't make sense to make an assembly line for one guy to run back and forth along, trying to get the work done.
The context it was *supposed* to work was one where you have a large team where a programmer was just working the "widget X" station of the assembly line. However, it turns out that code isn't *not* an assembly line, even if we make 5 layers (assembly line stations). Lower case "clean code" on the other hand (writing code that isn't obfuscated) is worth fighting for.
premature code cleaning is the root of all evil
And not cleaning code early enough is the root of your startup shooting itself in the foot
This is so true
seriously. instead of worrying if you're doing it "right", write that 50 line method and then take a second look. First attempt should always just 'get shit working' because half the time you might not know exactly what's entailed. Once you see that on the page it may be easier to recognize if there is a pattern and its worth a refactor.
@@anthonyparks505Indeed. Get a _slow reference version working first_ because it *doesn’t matter how fast you get the wrong answer.* By then you’ll have a deeper understanding of the problem to write a good solution.
It is almost as if everyone forgets _The Mythical Man-Month’s_ advice.
*Plan to throw one away, you will anyways.*
Who knew prototyping was an old concept! /s
So there was no evil in the world before we invented computers and started programming them. Got it.
I don't understand this whole mindset of "With pattern X I can't keep the whole problem in my head", the point of patterns is that you don't need to keep it in your head anymore. With a good pattern instead of specific memory layouts, index ordering, specific formulae, or whatever specific details a coder can now write to a contract. If the abstraction isn't providing a contract then it is a bad abstraction, If the abstraction is providing a bad contract for the situation then another could be better, if the programmer is constantly trying to pierce a good abstraction maybe they are just doing it wrong.
Real communism has never been tried.
I always prioritize writing clean and readable code first as this will make it much easier for you and your team to debug.
Most applications don't need the performance gain.
You see, it doesn't make difference for the final user if he will get the answer 1ms or 1 second after clicking the button.
But it makes difference for the user if you'll solve a bug in 1 hour or 1 week.
There are specific scenarios where the performance will make a difference and we only should spend effort on those specific scenarios.
Games, complex reports and highly concurrent applications/features are an example.
Even so, you still can write good and fast code, you don't need to trade one for another always.
Equilibrium is the key for everything in life.
Try writing readable code from the beginning but allow yourself to write worse code if necessary.
Every time I see “Clean code” book on developers table, I know that at some point of time (more sooner than later) I’ll feel a strong urge to bash its owners head with that book. Never was wrong.
I have a feeling that Bob Martin made much more harm than good for software development industry
Yes. to all of this.
"If you hire ten developers to solve the same problem, you will have eleven different solutions!" That's the real problem! Software is the creative expression of how a person thinks, how they interpret the world and the context around them. As you create abstractions, abstractions of abstractions, it will be a nightmare to maintain something that, theoretically, should be simple!
Martin Flowers itself already explained that not all code need to be clean.
And that no programmer, even himself write clean code. First you write code that works. Then you clean it, that leaves you with parts of the code that must need to be very effective, just stay that way, in those cases it is ok to leave a comment just explaining what you did.
Another point is that Clean code does not mean SOLID. What clean code stand is that the code must be readable(Understandable), and that could change from company to company, team to team. Regarding abstraction, clean code just say that you shouldn't mix levels of abstraction.
Levels of abstraction refer to how directly or indirectly code communicates its purpose, it has nothing to do with class abstraction principles or best practices in this context.
Clean code does not means slow code. If someone is saying that, then this person didn't understood clean code.
Martin argues that writing clean code is crucial for long-term maintainability and that performance should generally be a secondary concern in the initial stages of development.
Make it work, make it right, make it fast! (Kent Beck).
Performance first can lead to birty and bad code. This is not talking about writing slow code. Instead Martin Flowers says that poorly written code can generally lead to bad performance code. it's hard to identify bottlenecks and implement effective optimizations. On the other hand, well-structured, clean code makes it easier to profile and optimize because you can more clearly understand the code's behavior.
Especially in systems with strict performance constraints. Even in these cases, however, the code should be as clean as possible to facilitate understanding and future changes. But that there are situations that require careful attention to performance from the beginning
I think that people who attack clean code just don't understood what it is or just read the cover page of the book!
Hi Prime. Good video and I get what you mean how a "Clean Code" makes it difficult for you to understand what exactly goes in the flow.
And this is okay because one doesn't need to read 100% of the code most of the time. It is similar to the fact that we don't read every single line of a newspaper.; we skim through the headlines (function names) before we decide what article (the function body) to read.
In Clean Code, you don't get function calls like `array.holyHandGrenade(index)`. So there is no point in reading every single function body if it doesn't seem relevant.
If you're talking about the Clean Architecture, that's a separate story. AFAIK, the motive behind this architecture isn't writing a Clean Code but making yourself independent of the tools and frameworks (as Uncle Bob puts it, you can swap out the dummy database with a proper DB, etc. That is, you only need to rewrite a single layer of your codebase to replace your ReactJS app with a SolidJS app).
In my experience, you never do just "skim through the headlines" though, because when you're examining code, method names are generally insufficient to fully describe the contents, and more often than not are named poorly. Furthermore these methods are often thoughtlessly partitioned, with inter-dependencies, which is a big no. I find it annoying and disruptive to have to keep navigating to definitions. For these reasons, I think it is simpler and safer to just write monolithic long procedures. KISS is generally all you need.
As for your clean architecture example: that just seems like typical premature over-engineering. KISS.
@@tarquin161234 the reason is that you have only dealt with poor quality code. When reading a clean code, you can bet your life that a printUserInfo is not going to increment the user's age.
What you described is exactly what a clean and structured code will help you avoid.
@@SufianBabri Exactly, listen to this guy, real communism has never been tried.
I’d be interested to see some examples of “clean code” vs something you’d write. I hear this argument all the time and leave very confused. Abstractions are supposed to separate concerns, and I find that they help significantly because I also have trouble keeping that much state, but with abstractions, I don’t have to worry about implementation details when I intuitively know what something should do, unless it’s not working properly, in which case I can test it on its own. I’m wondering if there might be a disconnect due to my lack of diverse experience
Your code should be easily testable. If you can achieve it without "clean code", do it. There's a great talk called "Clean Coders Hate What Happens to Your Code When You Use These enterprise programming tricks" by Kevlin Henney, I think he's criticizing "clean code" the way you mean it (and many enterprise programmers to).
I think maybe there’s a bit of conflation here. “Clean Code” isn’t a monolithic standard. When I advocate for it at my work, I’m advocating for code that is *more* SOLID. But mostly it’s that I want to be able to look at someone else’s code and quickly understand what they are doing. Part of that is naming variables clearly - not using “x” “_x” and “__x” as variable names within the same scope. Part of it is inverting some if statements to reduce nesting. Some of it is using standard or accepted code styles and design patterns. I’m sure another dev could have higher standards and want everything tucked away under 10 levels of abstraction. I get that. And I get how hyper meticulous adherence to SOLID principles and design patterns can leave a sour taste and spoil the idea of “Clean Code”.
But just like a customer may not always ask for the right thing, or they may use vague language to describe a problem, there’s an underlying “need” that I want addressed when I say I want clean code. That need is for extensibility, stability and maintainability in the codebase. The tricky part is how we can come to agree as a team on what that standard should be because it’s ultimately subjective. The guy that writes sloppy spaghetti code with single letter variables and 6,000 lines in a method may still be able to quickly find things in his own code and that system may work for him, but other devs are in for a tough time if they have to touch that code.
Doesn't matter if the sloppy guy can read his own code. The code writer always knows his code intimately, no matter how bad, for a few months at least. As you're getting at,, the objective is making the code readable for other people.
I feel like a lot of it is. Well, don't go for performance if don't have. but maybe you should keep some eye on performance, but then again sometimes performance is paramount. This doesn't really say anything, here's an idea, think about your design constraints and goals, and use your best judgement.
I recently tried to read a project that was presented as an exemplar of clean code. It has literally hundreds of classes for a relatively simple web project. I found it franky impossible to understand what the bloody thing was doing. The cognitive overhead was overwhelming.
I'm in high performance computing and scientific computing, and obviously speed matters to us. There is a rule of thumb in HPC that say that any clock cycle your CPU, GPU, TPU or IPU do not spend on floating-point arithmetics is a wasted clock cycle. Obviously this is not entirely true, you need to read data from storage, you need send data between nodes and so on. However, it turns out that you can more or less reach this ideal by abstracting the calculations you want to do to operations on matrices, vectors or multi-dimensional tensors. The big issue with the code I see a lot of my physicist colleagues do is that they do not abstract enough and end up wasting clock cycles on index calculations and conditional statement that shouldn't be necessary in the first place if they had found the right abstractions. The point I'm trying to make is that abstraction is not necessarily the enemy of performance, it is rather a question of finding the right abstractions (which admittedly can be very hard). Anyway, I think it is a discussion is important, and yes in some areas of software development performance is not a big concern but in others it is.
Couple of months ago I was working in a personal project in js that needed to run relatively fast.
It was a cli tool that that did a few operations for about 3 million database object and had to keep a state while it was running.
I ran multiple jobs at the same time with a sync at the end that updated the state.
Like a good boy I followed the "good practice" of having an immutable state, so everytime there was an update to the state, I created a new object.
The code was running super slow because I was doing a lot of operations.
Then I did a little test and stared mutating my current state.
Suddenly the code started running infinitely faster.
So, I don't know, best practices sometimes are not the best option.
Clean Code should be simple code. If it is not simple it is not clean. If your definition of clean is adding complexity then you took the wrong things away from the book. With that said, I do not really blame people for taking away the wrong things from that book, the book doesn't do itself any favors.
The thing is, you can usually do both ; the Fast Inverse Square is an example of this - it makes ONE THING very fast and keeps it in a well defined box.
I've written my fair share of "fast but ugly" code. Most code should be clear and easy to read. If you can't do this, write good docs, and hide it behind a nice API.
I think part of the unspoken ideals of clean code is to not to understand certain parts of the code and not mind as long as it works but that breaks down the moment you need to maintain(modify) it
I love you're approach and agree with it, having readable code which follows simple patterns is waaaay better than seeing an over engineered code that I need to memorize.
I once had someone who hates inline nesting, so over engineering made him nest folders and files. Example: `Core/backend/src/intensive/runtime/postprocessor/Placer.ts` which is linked to `Core/Placements/Positioner.ts` and linked to `Core/frontend/src/Calculations/Math/OBB.ts` and all that function does was center a mesh on V3 0,0,0
But... if one needs to jump even once to understand what code does it's NOT clean code anymore IMHO. What you've described in this part were design patterns (and typical for Java inheritance overload) and that is completely different than clean code principles.
"it's also scattered around for my l1 and l2" right? that is my biggest problem with oot is when you read it it's hard to mentalize what's even going on.
Prime's take on this implies its impossible to both have a good architecture _and_ follow clean code principals.
I don't recall any clean code principals telling you to pick shitty architecture.
As a matter of fact, IIRC one of the very first things you see in the book in the saying "every programming problem can be solved with another layer of abstraction........except having too many layers of abstraction"
Which, while cheeky, is clearly telling you not to go to the insane lengths of abstraction that prime is talking about here.
that would be like dismissing all of functional programming because people are currying, or something, too much to the point where the code is hard to understand
I'm thinking the main issues with the backlash to clean code, agile, etc is that people take it to the nth degree. Sure they act as hard and fast rules, but rules only make sense when context allows them to. It's the adherence-at-any-cost that causes issues and friction. Sticking to planning things to make them quick, easy, clean, and effective (and only picking two or three) should really be the Northstar to guide things (imo).
Hope that makes sense.
Well, what I always use to say: You can solve problems a way more complicated than they actually are, but not the other way around.
8:30 The TF2 coconut is actually a myth, it exists in the game but it can actually be deleted without crashing the game. In fact the majority of the asset files can be deleted and it still plays with missing textures.
A different take on using a `Set` is it communicates to the reader it's a "set" of unique values, even when small. This might sometimes be a useful assumption that can be made.
I worked at a big DDD shop. They were all about clean code, abstracting everything, strict encapsulation and of course whiteboarding out everything. This always hinged on the requirements being correct. As we all know, requirements change and as you stated this leads to very time consuming and difficult refactors. At my current job we don't practice any of those things and I'd say I'm 5-10x more productive as we just build stuff with very little long term planning. It may not make you feel like you're playing 4D chess but you can refactor it really quickly. Not only that, you can look at it and understand what is happening much quicker.
What you are reading kind of reminds of going through "The Pragmatic Programmer" again. The book is helpful, but it's not a book I'd require at my desk.
Going for extremes is almost always not a good idea. Being an extreme "clean coder" just makes things less readable for others who are "less clean coders" than you. But we all have to agree that cleaning the code to some degree makes the code more readable and not less. We can apply some of the rules of Clean Code when they fit well while not be very dogmatic about the other ones... Just take the middle path, care for the code so that it stays as readable as possible without sacrificing too much performance and you'll be fine. The middle path is very often my path when I approach different ways of looking at problems in life.
Performant code can be written by anyone capable of thinking about hardware a bit, you can master it in a few college courses.
Writing clean and maintainable code comes only from experience.
Clean Code TM on the other hand can be taught in schools, which means you can get rid of the expensive, experienced devs and replace them with starving interns.
Yes! ECS is way to go! When you have N interconnected objects (geometry in some scene, actors in some simulation, etc) where state of one can depend on another, ECS is the only reasonable way to deal with all the unpredictable dependencies. OOP may be very inefficient and often introduces bugs that are hard to localise.
but ecs is not a solution for most daily problems, the majority of work getting done is a request-response pattern.
@@RogerValor This depends on a level. You can still have a request-response API or object, and an ECS underneath. For example, most databases resemble an ECS more than objects, but you have a request-response API on top of it.
I think the best approach to software development is to straight up write one to throw it away. 1. You have the option to get it to market faster. 2. You have all the unknowns now known. 3. You've learned a lot solving the problem.
You can get so much done by just having a conversation about a feature ... going off doing it... making decisions on your unknowns and coming back with something done... Then saying what do you guys like... what don't you like. I had these questions these are the decisions I made.
Then you go back fix those issues.. Make sure the customer is happy. Then get some automated integration tests around it. Then you engineer it. After that you can optimize it.
Is there an alternative to the "clean code" books that don't trow performance at the trash can? Is "code complete" any better?
There's an article called "Semantic Compression" and a currently ongoing course called "Performance-Aware Programming". Both by Casey Muratori.
@@etodemerzel2627 Thanks!
7:07 DATA-ORIENTED DESIGN, my favorite! tho not that useful on web. but love it!
Very hard to do correctly. And very inflexible for future changes...
its easier than any other way of coding
very flexable, easy to do changes
and a breeze
and still just gives you constant cache hits, and makes it super easy to parallel
@@nomadshiba I disagree. It would be more widely used then...
@@vladimirkraus1438ad populum fallacy
@@Cara.314 Just out of curiosity... have you ever built any non-trivial data oriented project and maintained it for at least several years while it experienced some significant requirement changes?
Check out the video: How NASA writes spaceproof code.(Mde by Low Level Learning!)
You'll have a good time!
I don't care about Clean Code or how applications are build as long as they are performant
I will be very happy if Microsoft send to me (free of charge) workstation PC - AMD Threadripper Pro 64 code, 2 TB RAM, 8TB Raid0 card and 3 GPUs to run their slow applications, because Microsoft thinks electron is modern tech
Yes many of those software companies have zero respect for their customers' resources
"YOU GODA COOK LITTLE BIT " And you know what now hang about 10 peaple team cocking there own thing.
Good code is simple, fast code is simple. Simple.
14:13 Wow! Yes! That is a principle I am going to adopt now! So easy and so obvious once you hear it.
The fast inverse sqrt is a bad example for the article to bring up. I get their point, but they are implying that there is a "clean code" alternative to that, as if putting the bit hacks into a virtual function would have solved the maintainability problem of that code.
I see it that way: Write your code in a way that your future self (and your fellow colleagues) will not hate you for in two months time. Because of missing comments, bad variable, class and function names, unexpected input ranges and return values, 2000 line functions, spaghetti dependencies and so forth.
If you don't work with other people or don't have to maintain sh1t, that is nice, but mostly your reality will be different. So do yourself and everybody else a favor and strive for quality first and optimize later where needed.
The table approach of the original video is so good !! Up until the point where your boss steps in and says "Can we do complex shapes as well?" And then the junior dev that inherited the stuff from the inventor genius that happened to leave the company scratches his head.
The fewer parts, linkages and abstractions the code has the easier it is to maintain. If clean code forces me to add more parts, linkages and abstractions then I would ignore it. I remember working with a clean coder. Long story short our team abandoned his framework.
Learning by doing...
Pretty much every company does code revision now.
So if you are not sure how to implement things at the first place, code it the way you know it works.
To find out redundancy of code is always the job of the code reviewer.
They should know how to abstract and guide you there.
In the end, it's all about communication.
Yea this kind of sums up my main problem as a swe.
I cannot wrap my head around very complex architectures. Sure its easy if i coded everything, but when its already done by someone else its HELL to step in.
This doesnt mean i code 1000 line functions, you kinda want to separate responsabilities, and want to have reusable components, but if you spend too much time jumping files to udnerstand where somethign comes from it becomes really hard to understand for others and really shitty to mantain
IBack when I cut my teeth programming, I prided myself on writing clean, readable, self-documenting code . This as opposed to some crap that looked like someone ran it through a Javascript obfuscator (this was in the dark days before automatic formatting, and also before Javascript, so not that dark). I also prided myself on good application of good design and programming principles. These were (and to me still are) separate concepts. I've never read Uncle Bob's book, but from what I gather, it seems to me that, in violation of his own "clean coding" principles, he has mashed together separate concerns and concepts into "clean code," which is now a loaded term. Perhaps he should have called it Good Code. It would be priceless to hear people arguing against writing "Good Code."
DI is good. Adapter pattern is nice. Polymorphism yes, inheritance, no. Well maybe when im feeling frisky. Ultimately the strategies we apply are domain and context specific.
Working with Clean code™ gives me brain damage. I'd much rather work with code that was structured to do its purpose in a way that makes sense.
Stuff runs on absolute minimum resource docker containers, bc companies don't wanna spend more than necessary - but lets talk about L1/L2 :D
very few scenarios where the microsecond or even millisecond improvement in speed by doing stuff inline is more important than writing code that is easy for the developer to read/maintain.
Once you start talking about l1/l2 cache and ram access, most people aren't even programming at the level since the memory and registry management is already abstracted away.
Well, if you want to analyse frequencies in a signal you can write a nice, clean, easy to understand Fourier Transform. If you want it to be fast enough that is actually useful you are going to have to write a Fast Fourier Transform. The latter is orders of magnitude faster and orders of magnitude harder to understand.
What is all the fuss about dynamic polymorphism? If you have selected an efficient language, say C++ or Rust, vs Javascript or Python, then you have already gained a huge performance boost, surely a little can be sacrificed for dynamic polymorphism if that results in a nicer design.
Its a tiny, tiny bit of the code that actually have any influence on performace. So clean code or not for the project does not matter, write the performance code in whatever style that gives performance and write the rest of the project in a way that is easy to maintain.
Deleting coconut is not blocking Team Fortress 2 to run, but the 2Fort cow model is you can't run game without the cow model.
About abstracting too early. TDD can aid with this. You write the simplest possible code needed to make the test pass; only then do you refactor. You only introduce abstractions if you find duplication or if you find a better way to solve the problem. But whatever you end up refactoring to, the tests have to pass.
You always start with the goal of writing easy to understand, maintainable code first. Only optimize as the need arises.
But if the code that is written is too inefficient to begin with, you can't optimize later if the need does arise without just rewriting everything from scratch. Yes, you shouldn't hyper optimize everything as you go. But you also shouldn't be ok with things being horribly inefficient even if they happen to be easy to understand and maintain.
I never want to hear "I've got a bush in my backyard" again...
There are so many things that the "Clean Code" people doesn't seem to understand. For example: Writing fast code doesn't mean you can't use abstractions. It just means they should be the right abstractions and you should discover them instead of prescribing them.
We use PHP, Docker, Html/CSS, JS at my job. Ironically compared to the rest of the code base which uses more of a functional programming perspective, writing even OOP with loose rules has sped up quite a few pages performance wise.
A lot of it has been preventing queries from running on pages that would never use the data.
My problem with people that avoid abstraction at all cost is that their code is unreadable, if i have to keep trace of varius nested if and loops to understand on a basic level what a function is doing even before starting to trying what caused a bug that is Bad code. Fullstop.
If you can write a function without nesting more than 2 level of if or loops, without invading other layers (i.e. i dont need to see literal strings in high level code to understand it, that should be a low level abstraction if possible without ruining the readability) then you are free of doing a 10-20 line function. Otherwise please estract. And if your function is over 20 rows and you don't understand that you need abstraction the problem is you, not people requiring you to write better code.
And if you need to go to the definition of a function not involved in what you need to change in your code... Then that is bad code, bad abstraction, bad programmer that wrote that.
I saw too much bad code due to just trying to avoid abstraction, and that usually involves using multiple side effects just because it feels easier to do to many, is important that code is easier to read than to write, if it is more difficult to read it than write it, that is always bad code.
Also most clean code approaces could be simplified by the compiler, when they are not there is probably something rotten in that compiler. Functional programming implicitly uses clean code (because it is a stricter approach than clean code) but older languages that used FP approach were as performant as C without having to use pointers.
The main problem in all of this is that programmers are lazy, and lazy solution are good at a low level and kinda bad at an higher level, just like in reality: learning to break an egg in a lazy way is good, learn to bee too lazy to preheat the oven when baking is very bad, you cannot reason as all task were low level memory hadling you will make people go insane.
There is guy on YT, he loves Mario 64. He would like it to perform great. He makes code of Mario 64 completely unreadable to save 0.1 nanoseconds
in my job people does not even know what a map function does so
they became frozen if you use a interface or just simple inheritance...
usually problem in these discussions is that there's too little context to give meaningful answer. What is the size of the team? How important the product is? What kind of developers there are? What is the domain? Probably at least 3x as many traits.
Many of my jobs recently have been some sort of ETL. There performance does matter in a sense that "can we run these 80M new entries in 4h", so data structures and algorithms are crucial, and pretty much never some bare-metal bit fiddling made any important difference. I'm sure many others have exactly other experience.
There's also the question of what "Clean Code" means. I'm fan in a way that I believe code is really hard to get even correct, if it's hard to understand, and writing maintainable, readable code is one of reasons why people try write clean code. What I don't like in Uncle Bob's approach is that 1) they are often quite OOP-centric 2) they are often presented like solution without a cost, whereas to me it seems like every design choice has cost included. All solutions derived from following say, SOLID involve these, if somebody says "there's no cost" I'll show you someone who's either a newbie or indoctrinated.
Yeah, pointing out Quake's FISR function is not super relevant in the context of clean code principles. I'd argue that the FISR code existing inside of it's own function is the most appropriate thing that they could have done to make that code readable. I'd agree with the author if that code was wedged inside of another function that's doing something else, but simply pointing out that it's complicated doesn't suggest that it was unreadable due to gaming industry practices and clean code violations - it's a complicated problem space that encompasses advanced mathematics. There's a reason they hired a mathematician to write that piece of code at the time instead of have a developer smash their head into it.
If you find the distributed code difficult to understand thats indicating that you have untrustworthy objects, its not an issue with the underlying concept.
So is Lambda Calculus the opposite of 'Clean Code' ?
Battle 1: Unit Tests VS Y Combinators
Yup with old code defo talk to the oldest person there. Ask if it’s been tried to be refactored and ask if there be ghosts in there waters
2:46 if you are able to "plan ahead" its a sign that the problem you are working on is not very complex. if you are actually work on things that are interesting, you can't plan ahead.
Here's my humble take on the matter:
Clean Code is not a holy grail. I have read all 17 chapters of the book; It contains very good takes on good, testable and readable software development. However, it also contains bad takes too especially: "Chapter 3: Functions". Much of the things in that chapter should not be adhered to at all. Functions can be too small and can also be too Large. I like the idea of the Locality of Behaviour and organizing files and folders by feature rather than by type better. Having multiple layers of abstraction that don't serve the purpose of encapsulating complexity such that one doesn't need to go source-diving to figure out what is happening is also not a good idea too. In addition to Locality of Behaviour, you need behavioral transparency to a certain extent too. Again. one cannot achieve this behavioral transparency without also taking a minute to name things well.
Also, I disagree with the HTMX essay that says Locality of Behaviour doesn't agree with ideas like Don't Repeat Yourself (DRY), or Separation of Concerns. I don't know where they got that from
There's nothing wrong with Quake's fast inverse square root, it's encapsulated in a function that a junior can use with no comprehension of the implementation. If you need to maintain it but don't understand it either get good or roll your own.
I don't usually agree with ThePrimeTime's views but in this case I'm 100% with him. I've seen too much code over-abstracted and shittified due to some arbitrary definition of clean code. The thing that sucks about clean code is no one has the same definition. I hate abstractions for the sake of abstractions especially when they add no value. One pattern I see over and over with "clean" code is moving relevant logic away from where it's actually referenced, making it harder to understand WTF is going on, especially when the code has a bug in it. I've seen code so "clean" that the entire stack trace dump isn't long enough to figure out where the error originated from. Fuck that.
Clean code tends to create so many abstractions that you can't keep them all in your head at the same time, nevermind understand what they actually do under the hood.
Primeagen's L2 is the chat
One side think clean code is human readable and unclean code is spaghetti entangled with spaghetti.
Another side think "clean" code is abstraction on abstraction, and unclean code is neck breaking fast assembly on a web server.
The reality is both of them are right and wrong at the same time.
Also what I don’t hear anybody say is despite these (idiotic) TDD, BDD, Clean Code bollocks it is proven that software lifecycle is shorter than ever. An average product lives 4 year before rewritten. And software now is the most crap or has been! Buggy slow inconsistent! So all these mantras need to go out and just write code performed low memory usage code again. Nobody is going to maintain your code period! And good performed efficient code is often easier to understand because you don’t need to ware through a layer of files and nested class hierarchies.
It just depends on the use case.
Some systems are intended for extensibility & clean code may serve some of those cases better. Others need performance, so screw clean code. I think most projects will go somewhere in the middle of spaghetti code & clean code.
8:35 it doesn't... it's a myth.
You can actually delete a lot of the textures in TF2 and still be able to play.
Performance for a web company is crucial. Performance translates to cpu instructions which translates to power consumption and time. Both of those directly translate to money. Add to that the more cpu instructions your code takes the more hardware it takes to support a user. Which can also mean more network, racks, power, ... Which again translates to money.
Throwing hardware at bad code is a poor decision. I can't even count the number of companies that failed because of that approach. "Premature optimization" is a firing offense with me unless you are ridiculing the term.
Clean Code is developers just programming for the developer, with little thought given to the impact on the end product. It's like writers writing for writers rather than their audience, it's an exercise in self-aggrandizement for self-important people.
You can write maintainable code that makes sense for the individual scenario while not neglecting performance in all areas. Abstraction layers should serve a specific purpose, like decoupling a specific runtime API implementation from the consumer code. A good example would be a graphics renderer API, maybe you want to give your program the ability to switch renderers between multiple target architectures and systems. Well abstraction serves a direct purpose there. Another good example is an entity component system because you can assemble complex objects piece wise at runtime based on a data set that changes completely independently from the ecs implementation.
Some people think clean code and single responsibility means literally every object can only do one thing, rather than a logical module that serves a clearly defined easy-to-understand purpose. If you're just making an object for the sake of separating functionality without any discernable purpose, ask yourself why.
the sentence : "adding a processor and memory is recommended to compensate for the lack of efficiency ", is an aberation on so many aspect
The good ol equivelence fallacy. Clean Code™️ != clean code.
I think of clean code as a grab bag of mostly good ideas for readability. But if you apply them all you get to an extreme where following the code becomes tedious. Also I love my gated code and will never give up multiple returns.
I may be wrong here but concept of "Clean Code" shouldn't be "follow this rules and this rules only!" Like it says in the video, concept of clean code is to organize development process and if you can write down your own internal rules and share them with your team-mates it should be considered "clean code"
Correct me if I'm wrong
2:00
Already I think he's missing the point of the video already which was that the code becomes unmanagable. It's like they watched through the first two examples maybe and stopped there. Polymoprhism is by far the smallest part of the video and the least controversial I'd say. Everyone knows vtable lookups are slow and that it obviously prevents any form of vectorization. But the parts that really stood out to me is how damaging the other rules are. The DRY especially.
Dry is mental masterbation
Premature abstraction is root of all evil :>
Performance isn't an issue on most apps. Until a competitor comes along with a faster app that does exactly what yours does and better, then performance becomes an issue. So if you don't mind being slowly driven out of business while you do a very expensive and impossible job of rewriting your entire codebase to make it faster, clean code is for you.