Clean Code is SLOW But REQUIRED? | Prime Reacts

Recorded live on twitch, GET IN
/ theprimeagen
Article link: betterprogramming.pub/clean-c...
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/deeznuts

[@davideastman5806]

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

[@TheAces1979]

🤣🤣🤣

[@ericbwertz]

By Clean Code, you mean TDD, of course.

[@a-yon_n]

I think what we really need is clear code instead.

[@bozzistef]

@@ericbwertz

[@TheSoulCrisis]

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.

[@JoshWithoutLeave]

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.

[@djixi98]

Again? lol

[@IIARROWS]

Now I know better. It certainly is something dirty.

[@iamhardliner]

They recently changed it from scrum master to agile coach where I work

[@xdman2956]

Me too, totally

[@ZephrymWOW]

​@@iamhardlineraka retards who haven't coded in a decade and are great at inflating delivery costs

[@taragnor]

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.

[@Smogne]

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

[@Rumu11]

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.

[@cinister]

As many in the chat pointed out, the TF2 coconut JPG thing was a joke that people took seriously. TF2 KZbinr 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.

[@temper8281]

I was gonna say, because the source engine seems like a really bad example for "poor" code given the sheer number of games that have been used to make it and over such a long period. I'm sure it has pain points but it's no way near a good example of "bad"

[@XeZrunner]

@@temper8281 It's actually quite a "personalized" code base, from the perspective of Valve. I'd imagine many of the same programmers have been working on the games that were made with it, so they were probably quite familiar with its aspects. Source 2 is/was a great opportunity to rethink the codebase and it's starting to mature with Counter-Strike 2 and S&box now.

[@scvnthorpe__]

@XeZrunner Valve are a passionate company and their tools are beloved but in general I'm not super happy w/ the code practices of the broader gaming industry Plus the work culture...

[@MichaelPohoreski]

@@scvnthorpe__ Everything wrong with AAA gaming: * *2003:* _I used to go into a store to find a game,_ * *2023:* _Now I go into a game to find a store._

[@simonkaran]

So basically a lava flow

[@daves.software]

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.

[@u9vata]

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.

[@daves.software]

@@u9vata at the time (2003ish) I'd never heard of Python.

[@lerubikscubetherubikscube2813]

I love that I haven't googled stlfilt and I'm confident in what that tool does

[@daves.software]

@@lerubikscubetherubikscube2813 :)

[@fededevi1985]

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.

[@TRex-fu7bt]

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.

[@ahmad_alhallak]

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

[@Aidiakapi]

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

[@MichaelPohoreski]

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

[@aaaabbbbbcccccc]

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.

[@stevenhe3462]

A pure function.

[@Xankill3r]

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.

[@Speykious]

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.

[@homelessrobot]

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

[@protox4]

@@Speykious I prefer the term "idiomatic".

[@etodemerzel2627]

@@protox4 *idiotic Sorry, I couldn't help myself.

[@casperes0912]

I think I have a very low tolerance for file length. Most files I want under 200 lines

[@Sledgeattack]

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

[@AlesNajmann]

Sounds to me like "The Legend of Zelda" in a nutshell 😆

[@hck1bloodday]

is a refference to mario @@AlesNajmann

[@litpath3633]

Ah, that classic star wars episode with john luke picard

[@styleisaweapon]

need more quotes like this to get the point across

[@pldcanfly]

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

[@SimonBuchanNz]

I'm infuriated! This is slander against programmers that drink lattes!

[@user-fr2fm3ri3w]

Haha this guy thinks 500kb of bloat is a lot, if he discovers electron he will go American psycho mode 🥶

[@mage3690]

​@@user-fr2fm3ri3wme too. A 500 KB file to do WHAT? Does the library come with a tokenizer so I can use a special operator to concat?

[@pldcanfly]

@@user-fr2fm3ri3w: Yeah... there is a reason I don't like that thing very much.

[@fededevi1985]

It is even more funny when your multicore multi-ghz moder PC does not even does the heavy lifting of rendering the page now as all the actually heavy tasks are handled by a dedicated gpu :D

[@anthonyparks505]

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.

[@reed6514]

Well said. It's all context dependent & there's no one size fits all solution imo.

[@Karnickel93]

@@reed6514 Yep, but how else should either side (clean coders or "code rebels") sell books/talks/workshops or make youtube videos, if all would take a more nuanced approach? /s Edit: Damn, I necro'd a comment thread

[@on-hv9co]

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

[@khatdubell]

Yes. There is so much push back on this (pun not intended). Most people will never hit the theoretical performance characteristics of more advanced data structures. My personal saying: Never pessimize your code on purpose, but don't try to optimize it unless you prove a need.

[@faridguzman91]

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

[@eqprog]

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.

[@jorgamund07]

Yep. My current rule is, unless there's a comment in the file saying "clean this up later", I leave mystery code alone.

[@robonator2945]

it's hilarious to me just how frequently people have to re-discover concepts that have been around for decades just because they're not directly applicable knowledge that actually gets taught. It would take 1 class period to teach the concept of Chesterson's Fence to people in 5th grade and solve at least 23% of the world's problems.

[@adriankal]

Those places in code must be well documented. If you use hack then add comment above it to indicate that it's a hack. XXX is for that.

[@karnadipa]

I have this experience with my own code 😅. I look at my code and think I make a mistake and change it and then I remember the reason why I code it weirdly.

[@Yay295]

The good thing is now that you understand the code, you can leave comments explaining it.

[@dadbod591]

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

[@etodemerzel2627]

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.

[@krux02]

premature code cleaning is the root of all evil

[@hamm8934]

And not cleaning code early enough is the root of your startup shooting itself in the foot

[@joranmulderij]

This is so true

[@anthonyparks505]

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.

[@MichaelPohoreski]

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

[@Elrog3]

So there was no evil in the world before we invented computers and started programming them. Got it.

[@ErazerPT]

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

[@Htarlov]

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.

[@diskpoppy]

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.

[@harleyspeedthrust4013]

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

[@jakubkoci]

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

[@anj000]

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.

[@MrAbrazildo]

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

[@MrWorshipMe]

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

[@godeketime]

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.

[@tordjarv3802]

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.

[@SufianBabri]

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

[@sqeaky8190]

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.

[@R4ngeR4pidz]

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

[@banatibor83]

Total bullshit. How much code you have to write for exploring something? Maybe a 1000 lines. Not your typing speed will be your greatest obstacle.

[@nchomey]

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!

[@haraldbackfisch1981]

R u sure he said that,bc it wouldn't make much sense since the two are not exclusive or even competing. OO and functional are. Procedural just refers to a more let's say exploratory way to code as opposed to TDD or something with a lot of organizational overhead

[@serhiipylypenko]

@@haraldbackfisch1981yes he did say that many times

[@haraldbackfisch1981]

@@serhiipylypenko that he prefers procedural over OOP?

[@nchomey]

@@haraldbackfisch1981 yes I think he has. Regardless, it would be an interesting topic for a video. What the differences are, when to use one or the other, different strategies, etc

[@NoX-512]

@@nchomeyThe answer is simple. Don’t do OOP (inheritance and polymorphism) unless you are forced to by the code base you are working on. Encapsulation is a good principle and not specifically OOP. If you have the chance, write as much code as possible in non-OOP languages as you can, e.g. Zig and Odin. It will force you to think in procedural/data oriented patterns rather than OOP. If you do it properly, you will find that your code becomes easier to read and maintain.

[@tjdgmlchl6305]

Man, the content you produce is so rich… both entertaining, insightful, and educational at times. I love it.

[@robertochostakovis]

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

[@strider5245]

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

[@RandomGeometryDashStuff]

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)

[@Broxerlol]

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.

[@Dominik-K]

I really like this, thanks for the video

[@billith6444]

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.

[@saikiranj807]

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

[@drxyd]

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.

[@anton9410]

great suggestion on the clean code video

[@ericmackrodt9441]

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.

[@mrnotpewdiepie8957]

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

[@KonradGM]

One of the thing i realised lately about all the Code talks is that a lot depends on what person works in. If you work in TS(JS+) you will look very differently at anything oop related than someone who works in oop language. And you will look very differently at oop if you use oop language, if you use paradigms cause they are "high level" vs when you need them and make them useful

[@thecyrilcril]

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

[@fajkoson]

FYI: William Kahan and K.C. Ng at Berkeley wrote an unpublished paper in May 1986 describing how to calculate the square root using bit-fiddling techniques followed by Newton iterations.[4] In the late 1980s, Cleve Moler at Ardent Computer learned about this technique[5] and passed it along to his coworker Greg Walsh. Greg Walsh devised the now-famous constant and fast inverse square root algorithm. Gary Tarolli was consulting for Kubota, the company funding Ardent at the time, and likely brought the algorithm to 3dfx Interactive circa 1994.

[@Daniel_WR_Hart]

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.

[@jeffsteyn7174]

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

[@LiliumAtratum]

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.

[@1Iljo1]

Reminds me of your padleft function in javascript. It was clean and way slower, but you WHERE PROUD AT THE TIME.

[@shygrammer]

This Guy says so much truth!

[@UNgineering]

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.

[@Rin-qj7zt]

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.

[@etodemerzel2627]

But do you split your big functions into a bunch of 3-line functions?

[@cronnosli]

I think that 98% of Software Engineers are not engineers but just glorified developers! If a Engineer is not good at abstracting thinks, than it is not a good engineer!

[@michaelhart8928]

There’s no guaranteed way to always do abstractions correctly. Many assume something that comes up much later when a lot of the system uses that abstraction. A good example is any abstraction over distributed components. Those are designed differently for a reason so can have extremely different fault tolerant design that needs to be accounted for in your app.

[@allalphazerobeta8643]

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.

[@luizfernandonoschang8298]

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.

[@jonb8869]

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.

[@tmvkrpxl0135]

I remember this being in my old source. I should revisit it someday.

[@denys-p]

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

[@homelessrobot]

Yes. to all of this.

[@tullochgorum6323]

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.

[@emptystuff1593]

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

[@AK-vx4dy]

Splitng functions to smaller has any effect on speed in compiled language, compiler happily inline them. Polymorphism can slow things but it can be avoided in critical paths and in many cases it is mostly static wich can be optimized also. Paradoxicaly interpreted or "JITed" languages can use tricks to flatten polymorphism and vtables if choice is not dynamic or is dynamic but change rarely. Games are specific they are mostly "write once", after premiere code will stay mostly as it was. Services in cloud should depend on better languages and tools wich be more efficient but not on dirty code.

[@AK-vx4dy]

@@oscarsmith-jones4108 I didn't wrote they don't. I wrote that deep strings of nested not polymorphic calls can be easily inlined to avoid real calls and returns. That is what clean code proposes, spliting problem to minute parts. Polymorphism can be costly but for example in strategy pattern this is static polymorphism, strategy is choosen once at object creation. I didn't measure it but IMHO more harm is in keeping arrays of real objects because when they big cpu can easily find way to prefetch. Also missprediction has no negative effect on speed per se, cpu can simply wait for final result or instead start to do some path, if wrong effect is the same as waiting. In speed critical apps data oriented design should be used, it is way better for caches. Any layer of indirection is also painful code or data, any random access to ram is a nightmare to speed. I know that inling it is not a silver bullet, but if code must be maintained for years, clean code is invaluable.

[@rzabcio3]

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.

[@joshuaworman4022]

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

[@vanthel]

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.

[@ShadoFXPerino]

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.

[@agatasoda]

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

[@u9vata]

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

[@williamdrum9899]

Non gamedev code doesn't have to be efficient

[@u9vata]

@@williamdrum9899Total bullshit. Especially when battery usage on mobile devices come into question, anything embedded, powertools, all kinds of tools - and generally very few software are there which should be totally pessimised for no performance... And then if you run anything on cloud you pay very high price for wasted compute in bills too...

[@williamdrum9899]

@@u9vata Ok, not as efficient.

[@etodemerzel2627]

@@williamdrum9899 Nonsense. I'm working on a project that's only used internally by 10-15 business people. You'd think that for a project like that, the performance wouldn't matter at all. But no, the users are complaining about the performance and have even given me the green light to improve it.

[@hck1bloodday]

3 line functions? thats seriously, a BS rule, but again, as the book said don't need to be dogmatic, my personal rule is a function should not need a scroll bar to see it fully, if you have to scroll, you have to refactor. again, that's for functions or methods, not classes

[@relhimp]

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

[@taragnor]

"Just use an array" can work well anytime the data set is small, because often times even an inefficient algorithm will still work okay with the benefit of cache locality that you get from an array, but once you deal with any kind of large data set the strength of the algorithm becomes paramount.

[@darak2]

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.

[@frydac]

I agree there is no correlation between clean code and lets call it good code, this means also that clean code 'can' be good code, and not necessarily bad or necessarily has very bad performance, while many seem to think it's all bad all the time. Used appropriately I'm convinced it can be quite nice, in my anecdotal experience it can be. Some ppl might then say: then it is not clean code, maybe not, but in many places clean code ideas are applied.

[@logantcooper6]

You always start with the goal of writing easy to understand, maintainable code first. Only optimize as the need arises.

[@Elrog3]

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.

[@rbaron7352]

Performance is critical for the backend. For example, points of sale have timeouts for transactions so any significant delay will cause the transaction to timeout. I worked for a company that had a process which summarized data. The stopped running it when it took more than a day to process a day's worth of transactions. After some analysis and rework, I got it down to less than 5 minutes per day. I was let go within 6 months of doing this.

[@Cyntacks283]

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.

[@datboi449]

the only time i’m a stickler for easy to understand/clean code is if you are a non-FTE and building something that FTEs are going to take over/support. for 300+ an hour it better be understandable.

[@deNudge]

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.

[@jaysistar2711]

ECS (Entity Component System) was created for access pattern based thread scheduling as well as polymorphism without the OOP drawbacks. It's widely used in the game industry where statements such as "You just didn't plan ahead enough." will get you thrown out of a room by designers, managers and programmers alike. It is both flexible and efficient, but, like Redux or Rust, has a steep, then flat, learning curve

[@estranhokonsta]

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.

[@abhaykatiyar3539]

Hi @prime I have been using clean code for a year or two, I actually don't see not that many issues , maybe it's because I am not that experience, could u suggest what else should I explore?

[@apollolux]

What's the specific Clean Code book being referenced? I'd like to read it so I can see what I ultimately agree and disagree with based on my own experience.

[@taklamak]

UI/UX === cadence:: user interaction => figure out where you have to cache/ do stuff, so that you get within your cadence-beat. Misdirect if you have to. Make it work. Make it fast. Super easy! Barely an inconvenience!

[@nomadshiba]

7:07 DATA-ORIENTED DESIGN, my favorite! tho not that useful on web. but love it!

[@vladimirkraus1438]

Very hard to do correctly. And very inflexible for future changes...

[@nomadshiba]

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

[@vladimirkraus1438]

@@nomadshiba I disagree. It would be more widely used then...

[@Cara.314]

​@@vladimirkraus1438ad populum fallacy

[@vladimirkraus1438]

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

[@MrJerryguy]

The most exciting part about learning to program is finally understanding the memes

[@blackmage567]

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

[@idocode1802]

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.

[@Impatient_Ape]

Younger devs usually have fewer responsibilities. Such things consume space in your brain's L1/L2 cache.

[@mage3690]

And stress is just a whole NOP sled to an infinite loop with infinitely recursing options, each worse than the last.

[@ThePC007]

@@mage3690 Yeah, the stress codebase really needs to be rewritten. :/

[@danielcoats713]

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.

[@klurman]

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.

[@Marksman560]

The faster you can type, the more code you can explore (write, try out, and understand), hence it's always a benefit.

[@ifeoraokechukwu1346]

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

[@sploders1019]

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

[@trapexit]

@6:30 Yes. Most people don't understand O notation.

[@ytdlgandalf]

Abstractions should be discovered, not designed

[@ooogabooga5111]

beautiful take

[@trapexit]

Polymorphism comes in many forms. Equating polymorphism with runtime dispatch is just technically incorrect. Overloaded functions are also polymorphism. At compile time.

[@arcilamatt]

Clean code works for me. First thing I read regarding architecture. what are some alternatives you guys like? Would like to research

[@SimonBuchanNz]

They mention data oriented / ECS, but generally it's just "write good code", where "good" means the simplest code that works. This sounds like a dodge, but really it's the point: following a necessarily small abstract set of rules rather than developing a wide toolbox of tactics, and the intuition in how to use them to keep things simple and easy is the problem. A good metric is minimizing the number of lines, but that's obviously bad to focus on only. A good metric is to write simple concrete code without abstractions, but that's bad to overdo because now you can't test in isolation. A good metric is keeping data and the code that operates on it somewhat separate but not too separate, or you're just asking to miss something when making changes. In other words: get good. Don't trust anybody without actually investigating how well what they claim works: not Uncle Bob, not Code Aesthetics, not Primeagen, and certainly not some random KZbin commentor!

[@arcilamatt]

@@SimonBuchanNz thanks for your reply 🙏. I generally agree with your perspective over the years I’ve read some cool things. The one other thing I learned pretty well from was Domain driven design. I never follow things strictly because I am not conscientious enough to do it 😅, but I have to say clean/solid code has had the most influence on me. Loved “get good” had a good laugh at that 😂

[@AlesNajmann]

Polymorphism with optimizing JITs like Hotspot and Graal is a very performant thing because it's inlined. It is something Casey M. completely ignores. Makes me wonder why?

[@LonersGuide]

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

[@reed6514]

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.

[@rbaron7352]

Even with an array, you can alway sort the array (Heap sort) and use a binary search on the array. Or if you really need a dynamic structure, use a hash table.

[@jef777]

20:48 this is what messed up the code base I am working on right now. Thank you very much.

[@tupak29]

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.

[@kevalan1042]

Primeagen's L2 is the chat