Clean Code is SLOW But REQUIRED? | Prime Reacts 

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.

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.

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.

If the code is hard to understand and maintain, then it's not, by definition, a clean code.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

I never want to hear "I've got a bush in my backyard" again...

I agree with most of the points, but my perception of what Clean Code is is a bit different compared to what is presented here. When I use the term, it simply means that the level of maintainability of the codebase is even more important than the functionality. I have met so many developers who were entirely focused on functional outcome and perceived maintainability as a second class citizen, which leads to systems that a horrible to understand and maintain. Clean code to me expresses the intent and thoughts of the developer who did it to reduce the WFT factor! The book is not an absolute, it is Uncle Bob's view on how to create maintainable systems and as you I agree with a some (probably most) but disagree with other. But I would never apply any heuristic religiously. Back in those days system and code architecture were the only means of improving maintainability. Today automatic testing has brought a really powerful tool, but just like production code, the quality and maintainability of you test suite is of utmost importance.

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

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.

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.

There is a value judgement going on here that the community went through long ago. Performance is important in KEY areas of the code. Instead of suggesting writing performant spaghetti maybe it would be a good idea to spend time with a profiler. There will always be certain critical pieces of code and at times taking some, well commented, shortcuts are warranted. Particularly inside of time consuming processing loops. However, most application have a lot of initialization, setup code, and teardown. Unless your building a game the user interface is usually not a contentious area for performance either. Building clean code may come with a performance hit but computers are so fast that its just not the problem its made out to be. If you make a jobs initialization 20% faster do you think anyone really cares? They care about the piece of code that processes the data. Having threads synchronize appropriately, is often another performance issue. If your program is spending much of its time waiting it may seem slow but no amount of fast code is going to fix this either. The only way out of this issue is a good design ( a profiler can help with this ). The other part of performance is using appropriate data structures. It doesn't matter what coding techniques you use, if you choose inappropriate data structures , you will create unjustified slow performance no matter how you code. Honestly, it seems like so many of these people have had interactions with code using inappropriate abstraction . This is a fixable problem that is much easier to deal with than other types of spaghetti. Honestly, these types of videos seem like they are written by people who never worked on large legacy projects. Projects where you can see the change in style over time. Project where you can see how no abstraction and spaghettis can get the software into serious architectural trouble. To summarize, if you want a good customer experience and fast responsive software this is barking up the wrong tree.

Hello guys Im stupid. In my codebase i need to draw 5 UML diagrams and 21 CodeMaps to change the colour of a Button. CC 4 ever.

Over the years, people have talked about Clean Code for more hours than anyone has actually written Clean Code

As many in the chat pointed out, the TF2 coconut JPG thing was a joke that people took seriously. TF2 RU-vidr shounic has a video explaining this, but the short answer is that while there is a coconut image in TF2’s files, it’s just part of an unused “coffee bean” particle and deleting it has no effect on the game’s stability.

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.

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.

I like how Brian Will described fine-grained encapsulation, "The princess is always in another castle."

"Paying our developers less because they can do more work for the money is more important then the performance of our apps." .... And that's the reason why my multicore-n-ghz-smartphone lags the F out with displaying a 350px wide webpage, while my singlecore 900mhz Pentium in 2002 had no problem with that. I'm just happy that when I learned programming we had to learn to watch our resource-usage. Today everybody is like "ok let's import a 500kb library to concat 2 strings together. More time to *sips latte, writes blogpost about stuff.*" And then I am sitting here and people wonder how I can search fulltext through 5000 rows of data and respond in ms. Like ... that's not magic, I just don't burden myself with 300 frameworks and ALL the abstractions known to man in between just to tell SQL to do a where. And that code is still maintainable.... if something looks like magic, write a comment there on the why and what... done.

I think it's wise here to take the good aspects and discard the bad. Writing a million 3-line helpers = bad. Giving things reasonable names and understanding how and when to use an interface = good. Writing shouldQueryIfConditionIsCorrect() to write something that could be expressed as a ternary conditional -> bad. Using enums and structs liberally with descriptive names instead of a million hardcoded constants = good. It helps to work in a codebase with very experienced colleagues who all of their own individual takes, that way you avoid any cargo culting of ideas from books.

WTF. The whole discussion makes no sense. Abstraction are there so you DON'T have to think about the lower levels. Any modern, even very low-level kind of programming lives on top of dozens of abstractions, microcodes, HALS, OSs apis, languages, languages stdls and multi level of libraries. Now you are using 20 levels of abstraction but 21 are too much?

too much padding there isn't much meat in the article.

Abstractions should be discovered, not designed

One of my favorite Bjarne tips was "just use a vector"

simple and readable code is much more important to me that clean code, ive seen design patterns and uber atomized components escpecially react codebases that didnt make any sense to me and was very difficult to provide any value or build new features

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.

Clean code is a set of guidelines. I don’t see why people are taking it as a all-in kind of thing. I don’t think Uncle Bob intended it to be either. I think in terms of performance, OOP is the real thing people have issue with. Sure, CC encourages the use of OOPs primary “benefits”, but I think that’s a result of being written for the majority of development developers do/were doing at the time. CC principles can still be applied to FP for instance. I also think that performance of any OOP or even any high level programming language is always going to be suboptimal. Frankly, if you truly need performance, ANY language other than assembly is going to have its cons. Performance is also not the same as memory usage, memory leaks are going to happen irrespective of CC or OOP. If anything, I’d say CC will help you to at least ensure you create abstractions that might be easier to find memory issues with. Smaller objects instead of larger objects should in theory improve memory usage - something CC encourages. I think people are putting the blame on CC unfairly… look at OOP and the programming languages themselves as the real “enemies” to performance.

premature code cleaning is the root of all evil

The bit at the end about refactoring something and arriving at the same conclusion as the original programmer is a trap I’ve fallen into several times. At this point I’ve learned that if I see some code that on its face seems just extremely WEIRD that there almost always is a reason. Sometimes I don’t always arrive at the same conclusion but I’ll understand the original reasoning more. Honestly it’s helped me get my ego in check, too.

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

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" ;)

As a Pastafarian, I find all this discussion of Clean Code very upsetting. All of my code is spaghetti code.

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.

2:50 I will never be tired of you talking about this. I was hesitant to start coding seriously for like 10 years because I thought that since I can't hold so much in my head that means I'm bad software engineer and I don't belong there.

You cant be pragmatic and at the same time put abstractions everywhere for no reason just because "in the future we might need a different implementation"

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.

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.

Highly abstracted code necessarily cannot deliver features faster unless every single feature request lives at the edge of your codebase. Good luck when a regulatory change swings by that none of your abstractions deals with. You cannot predict the future. Don't pretend you can with Clean Code ^TM. Abstractions are NOT extensible. >Reduce Developer time How in the world does writing abstraction on top of abstraction on top of abstraction in Clean Code ^TM result in "lower development time" over just writing the code that needs to be written? That makes zero sense. I would like for a Clean Code ^TM advocate to actually measure these absurd claims.

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

Prime, I think you've said you like procedural code as opposed to object oriented. It would be cool if you could do a video expanding upon that!

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

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

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.

Here's my hot take: Get good at planning ahead AND learn how to type fast. There's no reason to pick one or the other unless you're physically unable to.

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!

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 agree. But of course not with "clean code" trademark. Thats shit code.

I believe it comes down to the priorities of the project or of the company. There are several things to consider that can have very different priorities depending on the company: 1) Performance. It might be of a very high concern if you build a game that needs that top-notch performance and wow effect (not all games are like that) or data processing that need to process terabytes of data in short time to create reports. It might be low priority if you build a JS for a web page, it is not about animations, and nanoseconds vs miliseconds doesn't matter. It might be very low priority if you write a script to process a low amount of images or data and it does not matter if it will be done in seconds or minutes. 2) Time to market. It might matter if you either build a thing and run a campaign or loose client(s) or if you either build something in time or other company will start sooner with similar service. It might be even matter of life or death for a startup in bad position. Also, a startup might be not in a good negotiating position with a big company requesting needed changes asap, or the opportunity is gone. On the other hand, if you have working reputable product and only work on enhancements, time to market won't matter. 3) Budget. You might have some budget and either you can cancel project or try to finish it without sufficient funds to do it very well. Happens pretty often in startups with investors. 4) Maintainability, quality of code, developer experience. May be a top concern for a long-run strategy. May be not if your company just tries not to drown and needs to change fast and cheap or die. 5) User experience. Usually it is very important, but might be moved to the back seat if other considerations are deemed more important. a) critical - so if that thing is even usable at all (might be not important at all for example in early PoC projects, usually top importance) b) normal - so if that thing is easy and nice to use for typical use cases I currently work in projects where it is something in this order 5a, 2, 3, 5b, 4, 1 (working startup) or 3, 2, 1, 5a (PoC projects). This means that there is a lot of rather bad code. It is not totally unmaintainable, but it is also very away from SOLID or clean code. We rarely have time to refactorize. There are also these smaller PoC subprojects that we do - there we don't take any considerations about code maintainability. We make quick scripts with code from github and GPT, stich it together and try if it works or not. If it works and project is accepted to go further, we rebuild a production version with a bit different approach (with better architecture and code), taking only some parts of PoC. I worked in projects with priorities like 5a, 5b, 4, 1, 3, 2 which were into quality. Mostly quality for enduser or client, then quality of code (but nearly on same level as usually those are corellated). This dictated totally different approach. Same person working, different projects, different decissions - both about the general architecture and code. And it is not like I evolved or rather de-evolved. I know more about how to write good quality code now than I knew back when I worked in projects which were very into the quality of code. I feel it is more like a thing dictated by the business circumstances of the projects rather than decission based on taste and knowledge. I did not work on games, but I think that in games it is most usually 5a, 1, 5b, 2, 3, 4 with 2 sometimes going up the ladder when deadline is near. They need to make game playable, make wow effects, make it to the market quick enough / on time. This dictates even different approach. Another thing is that you can overdo any of these things and make matters worse. 1) You can overdo performance and loose quality in other areas. Like your code runs fast, but results are less precise or it is too fast for the user or controlling process. 2) You can overdo time to market and add features faster than users can grasp and accomodate to the changes. It can be seen in some mobile games - they grow fast into having too many options, many with some currency/payments attached. Gets overwhelming, especially for new players. 3) Budget. Sometimes cheapest option is to take a ready code or services from the internet... and then you get locked in with it and have hard time changing things or changing provider etc. Something might be cheapest in short to middle run, but not cheap in the long run if you count cost of adaptation. 4) Maintainability. There is problem how to measure maintainability directly and we really have only some approximations like less repeating is usually more maintainable, single responsibility is usually more maintainable, more abstractions is often more maintainable. Can easly go too far with those proxy measures and get code that is actually less maintainable and harder to grasp. Also, like stated in the video, can loose on performance or user experience. 5) User experience. You can add a lot of complexity trying to have best user experience possible. You can also fall into a trap of thinking that something very usable for you will be also usable for endusers. You then can make a some custom thing instead of relying on proven typical solutions. It is hard to think like someone else or like general target group. A/B testing is here to help of course.

Every CPU cycle you waste is a tiny bit of energy thrown away. Making your system 20 times slower means making the entire energy consumption of your service 20 times higher (at least, if you don't factor in costs required for cooling your hardware too). So if you're a company that cares about the environment and your carbon footprint, you should start by educating your developers on how to put performance first, ahead of their egos.

CC apologists always argue looking for nano seconds of perf is silly, but in reality I find we are often talking about 400ms per request vs 4ms. And when your que app has hundreds of requests or thousands per sec it starts to mater almost instantly. CC is an excuse used to explain bad code, it could be clean and fast its just easier to explain your bad code as clean code.

Wow, you are referring the video where man, who does not understand basics of programming are trying to say that CC is bad.... and you call it a good one... maybe try to think first?... Ill explain some basics so you can follow on by yourself: 1. A man rated 5 statements (poly, incaps etc) but they go down to two (poly vs if and compute vs table data). 2. He was wrong in poly vs table data: finding function by poly is following link therefore it is O(1), when if is O(N) - so he basically lied about performance gain. 3. Precomputed values are obviously faster than computing it but it is not mutually exclusive in CC - so he basically lied about performance gain. And that's it - all his statements are a lie. Next time, try to think before referring to such clowns.

I never had a problem with Carmack's sqrt. I always thought it was kind-of interesting. It's precisely the kind of thing you'd want to optimise. In my own job recently I first wrote, tested and profiled "clean code". Then I identified areas where significant improvement could be made with AVX2 and then I implemented that code path as a compile-time switch. That code is less clean and less easy to understand but the "clean" version is also there in the file right next to it so you can see what the intention is. The AVX2 code is 7 x faster!

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.

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 wonder when we started to program abstractions instead of machines. We've lost it. The computer is a simple machine that expends resources in order to transform data, if there is a way to do the same transform while using less resources, that should be the default. If there are ways to expend less resources with different tradeoffs, those should be exposed. If those options are harder to implement or read, or make future portability or maintenance difficult, the problem is in our tools.

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.

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.

Creating functions is making abstractions. So there is no conflict here. Doing abstractions is what programming is about. As you said doing abstractions correctly: "... put 15 functions in that file do that until you kind of hit that point where you're feeling I'm a little frustrated with my code..." It is the basic step by step process of creating and knowing your code as you create it. Even Uncle Bob say exactly the same thing in his clean code whatever. He even goes long on the problems of trying to abstract too early when we have the illusion that we understand the problem before even having written any code. It is just some principles based on pragmatic experience and the SRP and other wannabe principles are just some vocabulary about the structure of codes. You take what you want from it and do what you want with it. As needed. I think the problem is that the so called "clean code" that you saw were done by people who didn't understand clean code. They were maybe more old school Java programmers who like to abstract things just for the cheap feeling of it than for the need of code. That means that those were not clean code. A code with to much abstraction is dirty code, not anything else. Code as you wish and abstract as you need. That is clean code. Understanding the vocabulary and the principles is just like the design patterns. Only low quality programmers would say that those should be done exactly the same for every problems.

This boils down to a developer should know what the code they write actually does. Theories of “clean code” are a guideline, not biblical rules to be blindly followed. All this back and forth debate noise is circle jerking over semantics. Write a lot of code in different styles and you will see what is best.

It's a tragedy as a Java developer to run to the array. A bloom filter on a set will be much faster on whether the set contains something or not and cleaner.

Check out the video: How NASA writes spaceproof code.(Mde by Low Level Learning!) You'll have a good time!

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.

I prefer my code to be dirty AF.

I definitely think you're right about the "typing fast allows you to explore more", there is only so much you can figure out from reading the code and looking at the involved systems Once you make the change you increasingly get more context of the problem and might figure out that the approach isn't correct, has unforeseen side-effects etc..

Why do I feel like this article is written by yet another person who doesn't have a single clue what he's talking about?

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

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

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.

> Disregard algorithm - use an array Yes, but no. I mean, it's nice to have underlying array for your octree instead of crapload of linked lists. BUT! First I need to have octree if 3D spatial mapping implied. And that's mean you've chosen right algorithm. Can array hold BST? Sure. That, If you know it's optimal data structure to store your open set for A* search over your octree. So. Get the best algorithm. And then do it with array.

Oh, I like planning ahead. I dont like it when I implemented it and it turns out I can throw away 80%, make it eaier and do it in another way because of that single edge case that shows up when I'm almost finished... But I still like to plan ahead XD

02:14 yes, that's why webpacked and minified js is sometimes more readable for me that many js files (having access to both many js files and webpacked and minified js is still always better)

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

I agree: I saw "extremely clear code style" systems that are very-very hard to navigate because everything is spread around extremely... The most clean code thing I hate is the "cannot have more then 3 line functions" like rules... My friend worked in a project that had not just mediator patterns for example - but "InterMediator" patterns that mediate between the mediators and that kind of overbloat :D Also this guy seems to have not heard that Casey do not mean all people should optimize: just not pessimize like crazy. Also there are countless other ways of doing software than inheritance based virtual polymorphism... Not just static dispatch, but many ways to do things that are both maintanable and much better performing. Also the guy went from gamedev to non-game-dev and guess what they have easier bugs? Maybe not because clean code, but because gamedev is 10x more complex....

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

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

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.

Clean code is just horrendous amounts of indirection.

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

He always highlights everything except the first and last letter.

My first c# sharp gig. Simple app had about 7 layers of abstraction. Coming from classic asp, I was lost.

You did the best summary at the end: "do what the team does". If you're a performance junkie trying to squeeze extra cycles out of your react component in a "Clean Code" team building the next facebook, everyone will hate you. If you're a Clean Coder working on ethernet controller firmware team, abstracting everything, everyone will hate you. Collaboration > dogma.

Clean code is simple code, everything else is more or less garage

you can't keep track when you extract stuff? weird from my perspective because extraction is how i organize things. when a function grows to a certain point, it just gets easier to chop it up so that it functions more like a library, where i can simply click on function calls to go to the part of the code i'm examining, with good names that describe the purpose of the specific section so i can see the entire thing all at once. i guess it's how you use the tool that matters. perhaps our problems are different too.

10:22 Just put doom's inverse square code in its own function. Quick_Inverse_square() and it becomes clean...

DDD has much much higher correlation to maintainability than clean code. Probably the good code bases Prime was talking about had DDD

I think many if not most projects take major Ls from not optimizing enough at the requirements level, before writing any code or planning any architecture. There's nothing faster and cleaner than not having the code in the first place, so if you can find a way to do less and still have a good business outcome, you'll do better in every metric. Go back and read The Rise of Worse is Better every time you want to start a project or do something clever.

I develop control algorithms for embedded systems. Everything is highly optimized but it is readable and sustainable. The drawback is, you need a reasonable skill level in C++.

I know it's what no content creator alive wants to accept, but things like Twitter or FB are poor examples to use for those not using those platforms. The NPCs don't speak for me.

Good code is simple, fast code is simple. Simple.

I don’t think people understand what clean code is. It should make your code clearer and easier to maintain for you and your team. Even uncle bob doing things differently every time