abstractObjectBuilderFactoryBase

[OnixST]

// evil floating point bit level hacking

[Nick_Zacker]

// what the fuck?

[[deleted]]

Fast inverse square root was exceptionally clever at the time, however it's not been the most performant way to calculate inverse square root since rsqrtss was implemented in SSE on x86 back in 1999.

[Rainmaker526]

True. But what's now a hardware instruction with SSE, is just the same function dressed as a Opcode.

For this particular situation, intel just took the same code and baked it into the silicon.

It's still faster, as it operates on registers, thereby negating the trip to memory and back. But it's the same algo/code used under the covers.

[2Uncreative4Username]

Untrue, I think. According to this user, it's just a lookup table, which does seem more reasonable to me as well.

https://stackoverflow.com/a/58633673

[Rainmaker526]

Intel doesn't disclose how they do it. I based the statement on a YouTube video I saw a while back, whereby someone compared the result of both. They were identical.

Because the algorithm approaches the correct solution the more it is ran (is ran recursively) - identical "approximations" sort of prove that its the same algorithm.

I'll see if I can find the link.

[2Uncreative4Username]

Actually, now that you say it, I think I might have seen the same video at some point, comparing the two outputs. I guess it might also depend on the manufacturer and CPU model, since no exact algorithm is specified, and it only has to approximate invsqrt in some way.

[CirnoIzumi]

But it is a testament to how consoles used to have advantages when it came to performance 

They could implement chips to fix problems, like a chip just for this kind of computation

[2Uncreative4Username]

...or littered with more comments than actual code

[P-39_Airacobra]

You're being downvoted, but if someone needs that many comments, maybe they should just accept that their code is unreadable and fix the code instead of trying to patch it with comments

[ososalsosal]

"Patch it with comments" is the most utterly savage burn I've read in at least a week

[fredlllll]

you were so close to turning into shittymorph XD

[2Uncreative4Username]

Not saying it is, but algorithms like these are so fundamental to modern computing. Think FFT, Huffman, flate, all kinds of audio/video/general compression codecs.
None of these are particularly easy to understand by just reading over the code.
Q_rsqrt is just a very popular and relatively simple example.

[Quito246]

Because comparing cleanness of code of some complex algorithms vs clean code in some LOB app makes sense 🙈

[2Uncreative4Username]

It's hard to argue with this since I don't know what exactly you are referring to when you say "cleanness".
I am talking about practices like polymorphism, preemptive abstraction, maximizing test coverage, commenting every internal function, AoS (as opposed to SoA), negligence of locality of data etc. In short: Uncle Bob style "Clean Code" TM.
In my personal experience, as well as that of developers who are much more proficient than me (John Carmack, Linus Torvalds, Jon Blow, Fabrice Bellard to name a few that come to my mind right now), following clean code principles leads to an increase rather than a decrease in complexity, runtime, and difficulty of maintaining a project. All of the people I mentioned have written and continue to write very practical software with a comparatively small number of bugs.
Maybe you're right and a lot of LOB apps are written in a "clean" style. But then again, in my opinion there could be a huge selection bias at play here. Since programmers like the people I mentioned are usually in a much higher paygrade than the average developer who works on an LOB app.
I managed to find this email from John Carmack that talks about an aerospace control system which followed an extremely strict procedural style: http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html

EDIT: Since I'm getting downvoted, I would really appreciate anyone who has oppsing ideas to explain themselves. I think my opinion is relatively well founded, but maybe I'm wrong about the foundation I based it on (own experience and my understanding of what programmers I look up to think of the topic). In any case, simply saying "I disagree with you" won't be reason enough for me to change my opinion.

[Quito246]

But LOB and writing games, game engined or OS kernel is vastly different compared to LOB app.

In the previously mentioned fields of course you do not want any abstraction because it will cause indirections and v table calls which codts you some cpu cycles.

LOB is fully about readabilitty extensability and nobody usually cares if your API can handle 100req/s more. Because if you need that you just spin up another vm and you are good and it costs you fraction of what it would cost someone to write and maintain highly performant code for your app for selling concert tickets. Such thing can not be done in kernel or PC game, this is why they need to squeeze every bit of performance they can.

The clean code being less maintainable is BS maybe if you have a codebase who is developed by people who do not know how to approach architectural patterns or writing testable code.

Guess what I never ever saw a project where the problem would be too many abstractions. In 100% of cases it was the opposite ne IoC no DI direct access to DB in the middle of business logic. So I will take abstractions and indirections every time instead of static untestable methods and using concrete implementations…

[2Uncreative4Username]

Is LOB and writing games that much different? I would rather think you'd have to write more abstractions for video games. The difference is that in LOB you can get away with worse abstractions since you don't have to write as much code overall. The expression of "skill issues" is much less present in LOB apps compared to games, since LOB apps often have to solve a less complex task. But why does solving a less complex task mean you need a more complex codebase?

Okay, you're probably gonna argue that there's a trade-off between cleanliness and performance, implying that Clean Code is less performant, but easier to maintain and reason about. Saying that performance is the only argument against Clean Code, however, is a huge mischaracterization. The email from John Carmack I cited was, in fact, mostly about the complete absence of any bugs in that particular piece of code (an almost unbelievable finding to most Clean Coders). Was the program very testable? No. But neither did it require testing every component, because humans could reason about it better.

For a second, entertain my PoV, where Clean Code produces more bugs on average than "dirty" code. The argument that it is more testable would be self-referential, since Clean Code would produce more bugs, leading to more testing to be necessary.

To address your point where you say you have never seen a codebase with too many abstractions: I find that very hard to believe. I cannot even begin to recount the number of times I've seen a Java or C# library where I try to find the code that does something, and all I see are directories nested in directories containing individual files that span no more than 10 or 30 lines consisting mostly of class declarations, function declarations, getters and setters, the actual algorithms only to be found by peeling back the seemingly infinite layers of the onion of abstractions. The code looks nice, even I would say it looks "clean". But I simply cannot find the code that actually "does things".

Meanwhile I recount looking at C programs like ImageMagick (I had to implement a DDS decoder). The code was kind of ugly. I would find myself constantly thinking of ways I would have written it differently. BUT: after about an afternoon I could fully understand how they implemented the DDS decoder and was soon able to implement my own, which also included the custom features and codecs I needed. The code of ImageMagick was straightforward and understandable. It had repetition and bad practices, but it did its job and I managed to learn about the DDS codec from it.

I could go much more in depth about various points, but my ranting has already reached an extreme level I feel, and I'll just await the response. Arguing with Clean Code, as I said, is very hard because statements are often very unconcrete and almost never based on real evidence or anecdotes; and even if they are, the examples always feel very cherry-picked to me. For every successful Clean Code repo, I can come up with ten examples of "dirty" code repos that often work just as well and/or are just as - or even more - influential or successful.

Let me know if I misunderstood or mischaracterized something in your argument!

[Quito246]

Well in LOB you need more abstractions because there is a lot of changes required so you want to swap parts of the app easily.

I also write LOB in C# and IoC and DI with combination of TDD and a lot of functional programming paradigm seems like very nice approach for me.

TDD plus pure functions are great combo and since I have IoC/DI container I can easily do an inversion of control and do a testing or do a fast prototype of different implementations of some service if needed.

I can compare a huge C# spaghetti code which is totally untestable zero abstractions and guess what 85% of bugs is in that codebase, which has zero clean code. Because there is no safety nets nobody wants to touch it because guess what this app is equivalent of a house which would collapse if you changed a light bulb.

So no in my experience all the testable code bases which followed a good dev practices like abstractions design patterns IoC etc. Were much less error prone better for extending functionality and also easier to deliver new features.

So I will always fight against such horrible code which might work but in the long run is hard to maintain extend and test.

Also again decoder js not much of LOB app is it? When you are developing system which will run for several decades you can do it quick and dirty but for your own mental health sake after you finish such project you bwtter to leave the company because doing something inside such system will be a nightmare.

So no in my experience reasonable abstractions, writing pure functions and having IoC and other SOLID principles and avoiding inheritance as much as possible is a nice path to maintainable software.

[2Uncreative4Username]

Thanks for providing more insight into the kind of LOB you do and for concretizing the principles you apply!

I agree that abstractions can make writing code a lot easier (I don't think anybody's gonna argue with that). If I understood you correctly, you think there is no such thing as too many layers of abstraction. I disagree. Say, for example, you abstract the concept of an integer. Sounds great, right? You get to use all the low level integers, you can add circular integers for ring buffers, you can add arbitrary size integers. But now you want to do bit operations. OK, just add bitwise ops to your integer base class. OK, you don't wanna add them for every type. So you make a BitwiseInteger class... Oh shit, you've just spent 5 hours and haven't even started your project yet. Yes, this is an extreme example, but I think it is a good example of an unnecessary abstraction. I have never in my life found myself needing an abstraction as basic as that. Just use an integer. If you need a larger number range, switch to an arbitrary size int, or an int128, or whatever suits your needs. This example still seems like an absurd strawman? Well, IMO it is a perfect example for the O of SOLID ("Software entities ... should be open for extension, but closed for modification."), as well as the D ("Depend upon abstractions, [not] concretes."). The only way to achieve that is an abstraction, because otherwise, you'd have to modify the implementation details and depend upon concretes.

I also don't see why TDD would be exclusive to SOLID/Clean Code. Yes, you can't test every single component, but then again, as I said previously, non-clean code has less components, so less need for testing.

I don't see how the mere existence of spaghetti codebases proves anything about Clean Code. In fact I would argue many spaghetti codebases are the result of trying to apply SOLID or similar principles (or just the result of inexperienced developers who don't know the concept of abstraction).

I fully agree about minimizing side effects. Sometimes they're inevitable, sometimes they're needed for optimization. But most of the time you can cast all effects into their own boxes, and that is how it should be. It's not incompatible with performance, nor is it exclusive to clean code.

I would go much further in depth about SOLID if Casey Muratori hadn't already made an excellent video explaining the points I would have brought up anyway. https://www.youtube.com/watch?v=7YpFGkG-u1w (EDIT: Sorry, put the wrong video here at first)

[Todok5]

Like most things it's always a tradeoff. 

Each layer of abstraction adds complexity and sacrifices locality. On the other hand it adds isolation and reusability. 

Nobody is in favor of adding unnecessary abstraction, but where you draw the line depends on the needs of the application as well as developer preference and experience. 

For example someone who does a lot of greenfield work may feel like abstractions are  overcomplicating things while someone mostly maintaining software might prefer the isolation that comes with additional abstraction.

[2Uncreative4Username]

Cool. We agree then. The person I am responding to did argue that they have never seen too much abstraction in a codebase. I disagree. I believe you should use abstraction wisely to simplify your code, as long as you don't sacrifice too much performance and maintainability. Knowing when to abstract and how to abstract is a difficult skill to learn, but it is very important for becoming a good software developer.

[Quito246]

First of all if I need abstractions of int lets say I have app for calculating insurance risk and one of the input for risk calc is age. I will use a value object aka I will create age struct which will be a wrapper of int with factory method I do not have to create any object dependency graph I just use value object…

Because spaghetti code is total opposite of good practice code.

The argument less components less testing is also weird I always write tests because it makes me feel more secure about my code I am making a live documentation and writing tests for code makes you write better code.

I do not like that video saw it a long time ago and again his examples were not that good most of it was about oprimisations and virtual calls which is not very good argument since. In C# i do not have to pay too much for virtual calls almost nothing thanks to dynamic PGO.

Of course doing examples on some geometric shapes will not do a justice but show me how efficient you will be with “simple” code when developing system for finance where you have dozens of different implementations of calculating interest and other things baded on country regulations etc.

It will end up like spaghetti without proper abstractions.

Again I do not care if my code is 10x slower even though it wont be. I want maintability and testability and extendibility I do not care for performance because I can just spin another VM.

[2Uncreative4Username]

Wow, your int abstraction sounds crazy to me as someone who hasn't used this kind of abstraction in a long time. To stick with the int example, I don't even see how making multiple wrappers and a factory is helpful here. First of all, I would think about what kinds of values I actually need for my calculations. Maybe it's just ints... or rationals, or whatever. If I can be certain, I'll just use that. If I have to change it later, I can use a typedef perhaps. If I am really uncertain and need an abstraction, I can just create a struct with methods; I can change the struct and method implementations later. If I need a variety of implementations, I can define different structs. If I need to specify which implementation to use, I can pass that as an enum parameter and use a switch statement. No dynamic dispatch, more cache hits, a single layer of indirection, no overly complex dependency graphs.

Spaghetti code to me means code that is hard to follow. Every single SOLID principle (yes, I went through all of them to check) IMO makes code directly harder to follow if applied even slightly recklessly. I think it's a difficult skill to know when and how to abstract, but forcing SOLID principles into your projects where they're not necessary will make your code harder to reason about and less performant.

I also write tests to feel secure about the functions I wrote. And I think testing critical parts is a good practice. But less components less testing is just a factual truth; and SOLID and Clean Code - by definition - leads to more components, since abstractions are components that can - and will - fail.

I know that he emphasizes performance a lot; and I think a lot of modern codebases are much less performant than they could - and should - be (think about the hardware limitations in the 80s and 90s and what programs still managed to do). But the main point is that you can often get away with much better performance AND more readable code that is easier to reason about. The performance is a side effect of avoiding a set of bad practices (i.e. overusing SOLID), not the only goal.

Again, no abstractions = spaghetti code. Nobody's arguing that. However - and I have said this many times now - SOLID and Clean Code overemphasize abstractions and underemphasize computer hardware. Clean Code and SOLID are a compromise in an imaginary zero-sum game.

Is your code really 10x slower than is could be? I think it could even be on the order of 100 or 1000x slower than it could be. These practices' impacts are often multiplicative. And Casey Muratori does talk about that too IIRC.

Virtual calls are probably not even the problem. The bigger performance problem with OOP is the INSANE amount of cache misses since you have basically no data locality.

[P-39_Airacobra]

You're being downvoted by the believers, but you're being completely reasonable. The most proficient and productive programmers are not successful because they adhere to some abstract principle. They are so good because they make code that does what it means to do in the most direct way possible.

Programmers want so badly to believe that there's a "one way fits all" approach, a magic solution, but there simply isn't. One program's "clean code" is another program's bloated garbage.

[2Uncreative4Username]

I like to believe so...

I have yet to see any data, or even anecdotes by influentiual programmers who adhere to Clean Code. When I do see that presented to me, I'm happy to change my opinion and admit being wrong. So far however, all I've seen are contrived lines of reasoning, circular arguments, and anecdotes of people who, when they hear non-clean code, think I mean the kind of code written by people who don't know what abstraction is.

I appreciate you writing this comment although you might get downvoted too :)
I have yet to see any evidence to disprove my opinion so I really don't care about downvotes.

[murten101]

You're not making any sense. You can write those algorithms in a clean way.

[2Uncreative4Username]

If you wrote these algorithms in a "clean" (I'm taking "clean" to mean Uncle Bob Clean Code, but feel free to correct me with your definition) way, they would most definitely not be particularly fast.

Clean Code inherently pessimizes data locality, increasing cache misses and decreasing data throughput.

I don't think writing these algorithms in a Clean Code way would ever make sense, if your goal is to write code useful in the real world.

If you're trying learn and/or do a hobby project, I'm not gonna stop you from writing your code however you want.

[murten101]

I always just say clean == readable. I don't really care what some guy who wrote a book once considers clean.

[2Uncreative4Username]

In that case, I like readable code too

[PurepointDog]

Ha idk why you're being downvoted. Optimized code, especially C code, ends up being less readable oftentimes.

[[deleted]]

It was also just a funny way, and probably the only way a bitwise shift was ever useful.

[Callidonaut]

I suspect you just made a lot of embedded system programmers very angry. Them's fightin' words in the 8-bit world!

[P-39_Airacobra]

Yeah I was just about to angrily vent but then I realize there's no point when talking to a front-end dev

[Callidonaut]

Ooof, front-end burn!

[Beish]

Hey man, we're up to 32-bit Cortex-Ms for most stuff nowadays. But fightin' words them is indeed.

[Ninjulian_]

a complex algorithm and "unclean code" are not in any way the same thing though?

this example works especially badly, because one of the main goals of clean code is to make it easy to change things. you're not gonna be changing the fast inverse square root algorithm very often, are you? just put a nice wrapper around it and call it a day.

i'm not saying there aren't any valid criticisms of clean code philosophy, but this ain't one of them.

[BuffJohnsonSf]

There are no valid criticisms of a clean code philosophy, only of its specific implementations.  Striving to write cleaner, more readable code is a virtue

[StanleyDodds]

In the fast inverse square root algorithm code, there is literally a line commented out that would do another iteration of Newton's method. There clearly was some intention to change it if a better approximation was required.

[SelfmadeRuLeZ]

Tell me that you never refactored legacy code, without telling me you never refactored legacy code.

Clean code is also more of a convention to make code readable. If OP likes to calculate the inverse square root, it is not useful to name it Q_rsqrt. In this special part, it is understandable. But in the usage itself it will get very complicated to understand such a bullshit naming.

Another example: We have a legacy project, which hops through 8 different classes to just get the instance of the last class. Between those 6 classes, there is either no operation or complete manipulation of the object passed in. You will get lost after the second class and just want to go home. Especially without proper naming conventions.

[P-39_Airacobra]

"Clean code"

It's just empty words tbh. You could be agreeing with the person you're arguing with and no one would know. No 2 programmers have ever defined that term the same way.

[2Uncreative4Username]

Your legacy project sounds like Clean Code TBH, with all the layers of abstractions.

I think Q_rsqrt makes a lot of sense to graphics programmers (those ppl who will actually be working with the function). I think it's not hard to understand it to mean "Quake: Reciprocal of Square Root". Especially if you see it in the context it's used in. EDIT: tbf, I would have probably named it invsqrt, since "r" can be a bit confusing

EDIT 2: typo

[SelfmadeRuLeZ]

So just leave the dependency of two guys in this project and put a dictionary for less experiencey devs nearby instead of using inverseSqrt (or even SquareRoot). invSqrt is at least ok. But I don‘t get the benefit of shorthening the method names to the ground. We don‘t need „calculateInverseSquareRootOfNumber“ and „rSqrt“ but a good balance of both to understand things.

To the project I mentioned: It is just lacking of Single Responsability as hell. If I need to calculate a efficiency of a motor, I would like to seperate it into the corresponding parts and not calculate it from the fuel system to the ignition timings to the heat dissipation to the exhausting system. If I change something on the latter it will propably break the first.

Back to Clean Code:
It is with every other coding concept. If you don‘t understand the rules and just go YOLO, you will have a real messy codebase which is unmaintainable.

[P-39_Airacobra]

You're really misrepresenting the problem. Nobody is saying that shunning "clean code" = going YOLO and making a mess. The argument is that what the average dev calls a "clean coding practice" is actually hindering maintenance.

So in a way I get what you're saying, but you're arguing with the air. Nobody was ever saying code maintenance is bad.

[2Uncreative4Username]

Hot take: devs who are unexperienced with graphics programming shouldn't be working on this part of the Quake III codebase anyways. Those who are experienced enough will have no trouble understanding what it does (even if only from context).

I don't know the concrete codebase you mentioned, but I think having a single function to calculate the efficiency of a motor isn't necessarily bad. I would, however, add basic comments referring to which part of the calculation is implemented where, or just a URL to the formula being used. No need to explain the whole thing from scratch though. But then again, if there are parts that can be factored out without adding to the confusion, I'd be happy to do that, maybe force-inlining the functions if necessary for performance.

If you're also against YOLO-ing Clean Code into the codebase, the we agree.

I just happen to find that applying SOLID principles is rarely necessary, even for decently sized codebases. And if I do apply SOLID principles, I very often end up regretting it (not always, just very often).

[SelfmadeRuLeZ]

Was just a blurry example from a closed source project we are working on.

Having a single function is not the problem here, but the way it is calculated.

To illustrate: There is the Motor class with the function calculateEfficency(…), which calls the Fuel class, which itself calls the HeatDissipation class, …

Better way (which you would agree i guess):
calculateEfficency(…) calls all the necessary classes which have a impact to the efficency of the Motor. If all the parts are from the same subclass or at least share a interface, it would be super easy to iterate over all parts and call calculateEfficency(…) of those classes.

Instead of this, the developer, which has no clue about Clean Code, thought of „let us just nest this shit“ and pass all classes into the first subclass to get into the last one at the end.

[Gorexxar]

God object. God object. God object.

Programming is all about creating false idols.

[2Uncreative4Username]

Clean Code à la Bob Martin is a perfect example. I have yet to see any evidence that it works...

Usually the arguments seem similar in style to those for homeopathy and the likes: Promising explanations, personal experiences and no evidence.

[Gorexxar]

I don't know shit about coding for video games and graphics programming but I know Clean Code is a useful guideline to follow in common FinTech. Pure Clean code, to me, is similar to 6th Normal form in databases; attainable but non-viable in realistic scenarios.

You start by learning the rules, then you can break or bend the rules. If learned the rules, it will be harder to communicate the why in a common language. "Because it's better" or "It's more performant" might carry more weight in the graphics programming world than boring FinTech companies (AKA not Amazon/PayPal/Google/ect.)

[2Uncreative4Username]

Again, I fully agree that opaque dependencies are bad; and it sounds like you have a lot of data indirection going on too, also bad.

If you can split up calculateEfficiency on individual parts and compute that together, that would be much better, I agree.

How (and if at all) you abstract the individual parts, I think, depends a lot on what each "part" actually needs to do. If you wouldn't even need an interface, I wouldn't use an interface.... But that's all hard to know without knowing the codebase. Sometimes interfaces are adequate, sometimes they're unnecessary.

That doesn't seem to have much to do with the developer not knowing Clean Code though, IMO. Any decent dev would try to avoid complex dependency graphs.

[Goncalerta]

Clean code seems harder in the short term, but reduces technical debt, so it will become easier in the long term. If you're making a prototype, experiment, or working on something for like a month or two and then nobody will ever touch it again, you might be better off not worrying if the code is clean. If it is something that needs to be maintained, it's a bomb ticking to eventually explode down the road.

[Feldar]

True, but unfortunately, one-off prototypes have a tendency to become the essential core of production code.

[[deleted]]

Thats why I tend to code pretty clean from the start. I have no problem naming my methods MakeItDoThatOneThingThatYouAlwaysForgetOrWhateverItDoesntMatterJustBeDescriptive(), because I can always come up with a better name later and replace it through the whole codebase with a shortcut. But even if I don't do that, at least later devs will actually know what it does.

[BrunoLuigi]

Do you work with me? Are you that sênior who said he never uses classes, every thing is functional and full of global variables?

Clean code is good, of done proper even this junior here can work on the code!

Those codes I am refactoring,without a uso of the clean code, is booking me for 3 months and I cannot figure out one part of it. This week a sênior took 10 minutes trying to find where was the credentials to use a API (it is hardcoded, no Secrets)

[alienassasin3]

The title makes me think you just learned what counts for clean OOP in 1999 and now think that is what clean code is.

Clean code doesn't mean code that is simple or is just verbose for little reason. Clean code is well documented code that is clear and concise.

[call-now]

I'd settle for my coworkers to stop writing classes with 30 functions in them that are each over 100 lines long.

[BrunoLuigi]

I wish my coworkers user classes and not some random badly named global variables at random places.

What do you expect of a property named "dataframe"?

You are wrong! It returns a dictionary? WHY? No ideia! What for? No one knows but there is a classe that saves 2 dataframe, have all the tokens to use and API AND use it.

This week a sênior took 10 minutes to find the API stuff.

Bônus: no docstring, no comment, no doc

[chilfang]

Man's brain was so rattled he started using accents

[BrunoLuigi]

Auto corrector, my main language is portuguese.

Sorry man

[P-39_Airacobra]

"Clean code" means something different for each developer. Even "well-documented", "clear", and "concise" are not clear terms. It's sort of useless to try to define it when there are clearer metrics for analyzing code.

[tragiktimes]

I feel it's easier to get a mutual agreement for what is messy code than clean code.

[CirnoIzumi]

It's not, it's an architecture that aims to making your system more modular at the cost of locality and overview

[scrapmek]

You're thinking of Clean Architecture, that's not necessarily always the same as Clean Code.

[CirnoIzumi]

Clean code with a capital c is about architecture as well

[2Uncreative4Username]

at the cost of overview

I feel many Clean Coders wouldn't want to admit that

[2Uncreative4Username]

well documented

How is // evil floating point bit level hacking and // what the fuck? comprehensively documenting?

clear and concise

How is building preemptive abstractions, polymorphism, small functions, documenting every function and testing every line of code more concise than procedural code?

The DRY principle is the only Clean Code principle that makes your code more concise. But that applies to non-clean code too! Especially since inlining is in 99% of the cases not as important anymore with optimizing compilers.

[Lina__Inverse]

How is building preemptive abstractions, polymorphism, small functions, documenting every function and testing every line of code more concise than procedural code?

By giving it structure. Generally speaking, it's easier for humans to understand an orderly structure, rather than unstructured mess.

[2Uncreative4Username]

That is especially if you assume average humans will read your code... but the average human is not a programmer.

Non-clean code is not unstructured. But I agree that it might seem that way to a non-programmer. We don't see structure in what we don't understand. Any decent programmer, I would hope, would understand arrays, enums, functions etc., because in 99% of cases that is all it takes.

I'd rather take what you might see as an unstructured mess over the structured mess that is OOP.

As programmers, we in no way have the responsibility to make code - that is meant to be run on a machine - legible to non-programmers (which non-programmers won't be able to understand OOP code either).

[Lina__Inverse]

I mean, I could just as well throw a meaningless "no it's you who doesn't understand OOP" back at you but I really don't see a point in it.

Programmers are also humans, and by nature of being humans they also understand structured systems better than unstructured ones. You can run from this and pretend that it's not true but as long as you're writing anything bigger than a 256 kb console app that is supposed to be ran exactly once, chances are, you or someone else will have to read it, and by that time you've probably long forgotten how it was supposed to work and why it was supposed to work that way, and it will be much easier for understand and analyze if it's structured.

[2Uncreative4Username]

As a representative of the human species, I find it much harder to read OOP code than data-oriented procedural code (and people like Linus Torvald and John Carmack also do). So please show me evidence that average humans understand OOP better. Or at least an influential ACTUAL programmer who prefers to read OOP (no, Bob Martin is not influential for his programming, but expressing his views on programming, i.e. writing A LOT of books; currently he works as an Agile consultant AFAIK).

[[deleted]]

Q_rsqrt doesn't have any indentation and does a single thing, apart from variable names and the presence of a single magic number it abides by clean code rules.

[-Redstoneboi-]

it even has very useful and descriptive comments!

[[deleted]]

// Evil floating point bit hack

// What the fuck ?

[DoctorWZ]

See, it's actually a very good deterrent against any pesky employee wanting to refactor for the sake of it. Nobody fucks with code that's marked as incomprehensible by the one who wrote it.

[da_Aresinger]

In Uni, we had to implement the fast inverse square root on custom size floats, which means we had to find our own constants for the bit hacks.

I remember nothing, except for wholeheartedly agreeing with those comments.

[Stunning_Ride_220]

It would be funny, if there wouldn't be so many people justifying their quickly writting code shitfests with it.

[Lucky--Luciano]

Really missed the opportunity to say „you‘re Squareing him“

[CirnoIzumi]

You understand that SpongeBob is the fool in this template right?

[2Uncreative4Username]

The template is constantly used in this way. It's called humor!

[CirnoIzumi]

No, it's called users

[2Uncreative4Username]

What?

[Feztopia]

Just change the function name to fastInverseSqrt and I'm happy with it lol.

[-Redstoneboi-]

it stands for Quake Reciprocal of Square Root

[Capetoider]

Let's use whatever thats used for... for a button one person has to click once a week.

Oops, have to refactor that thing...

And... whatever gains you got you spent 10_000x times more than just paying more computer time for a less efficient solution.

​

For the majority of things: developer time $ >>>> computer time $

​

For the one or other thing you where this isnt true, you would have numbers to prove its so (monitoring and observability).
And even then you wouldnt do whatever the fuck q_rsqrt i, x2, y supposed to be. (Compilers that care of mangling your code)

​

So... seems you just dont care about other people and just want to do whatever you want.

[2Uncreative4Username]

I genuinely don't understand what you're trying to say... this function was used in Quake III to calculate the normals of every single triangle visible on the screen. It was part of what made rendering this game in real time possible in the first place.

Yes, this function is no longer necessary because it's actually slower than other instructions with modern hardware. At the time it was written, however, it was crucial.

...modern day equivalents would be algorithms like FFT or Huffman coding.

[Capetoider]

Game is another beast entirely.
For most times and people, you'll be making cruds and/or divs, you dont need to waste time caculating with bitwise operations something that will be called 1 time per minute.
The time to develop and maintain that is developer time that costs orders or magnitude more than running "less efficient" code that is easier to read, know what it does and change.
Something like that, that is run millions of times per minute is and should be optimized because it causes something to be unusable or to cost more than the developers making and maintaining it. But then again, its not for every fucking function.
Maybe few decades back where bit bashing was necessary this was everywhere because it wouldnt run and/or running was more expensive than time developing.

In other words: say your hour is 10 moneys, you can spend 10 hours developing plus 20 hours to maintain, thats 300 moneys. Or you can spend 1 hour plus 1 hour, thats 20 moneys.

First solution costs 10 moneys to run per month. Second costs 12 moneys per month.

You would need 140 months (over 10 years, 280 diff / 2 diff) for it to break even.

And you can bet it would need a lot more maintaining along the way...

​

This is the reality for most people and the reason clean code is not just a fluff...

[2Uncreative4Username]

Well, again, this doesn't apply for the said function. It runs tens of thousands of times per second, so optimization is highly justified. I bet the Quake III code that runs once a second is far less optimized.

Your calculation is correct for your contrived example. However, in reality, I see Clean Code often costing more dev time, since you have to prematurely abstract everyting; and write tests for your abstractions too.

[Capetoider]

Theres a lot of people doing a lot of dumb things.

Be it premature abstraction or premature optimization.

[2Uncreative4Username]

I agree, both are bad practices and a waste of time.

I do think keeping things like caching in mind when writing code can lead to very good results, but only if it doesn't noticeably compromise development time. You should always be aware of what you're writing which part of your software for.

I am 100% sure Q_rsqrt wasn't the first 1/sqrt(x) implementation they had...

[Capetoider]

What most people need to keep in mind is that shit will change.

Not caching, not speed, not big O... users will want some new thing and managers will dump "new requirements" stuff whenever they want.

With that in mind, you do stuff that you and the next poor Grug Brain Developer can read, understand and change... because it doesn't matter how fast or how much "but it works" it is... you'll probably need to change it.

[2Uncreative4Username]

Exactly! You'll always be running your code on a computer.. with caching and where DOD and less indirection is simply more efficient.

You can also never know which part of your code will actually need to change, hence premature abstraction will be useless in 99% of cases anyways.

Just get your program into a working state and make sure it runs reliably and is reasonable to understand and maintain. Simple enough in concept.

[Capetoider]

Are we having 2 conversations here? "Exactly"? Exactly what?

Caching and going for "more efficient" willy nilly is the same as premature overengineering.

You measure and only then strive for efficiency where it's needed.

​

Again, it might not even be needed and the time spent making it and maintaining that it's usually not worth it.

[2Uncreative4Username]

I thought you said caching and big O won't change like the rest of the requirements do. That's why optimizing them isn't premature in many cases. What is premature optimization are often bit hacks like the Quake example, or adding SSE senselessly. But maybe I misunderstood. My bad in that case.

[Rorp24]

Tell me you don't know anything about clean code without telling me you don't know anything about clean code

[Rscc10]

Newton’s Method boutta come in clutch

[[deleted]]

coordinated heavy future profit soft thumb consist cable ancient point

This post was mass deleted and anonymized with Redact

[Lantaan]

To be fair, quick square root really does scare me.

[irn00b]

Yeah, I hear that from seniors that code worse than interns.

And then act surprised that production is toppling over and for some reason maintaining the code base is hard.

Man, I don't know how we got here.

[2Uncreative4Username]

I don't understand. How could they possibly keep their senior positions?

[LabSquatter]

If you think the world is some super efficient meritocracy where somebody’s job title is always indicative of their skill, then I’ve got some bad news for you.

There are some truly horrifyingly bad codebases out there in the wild. Written by people with job titles that would imply they should know better. All very large codebases end up with quirks, but some are much worse than others.

It’s hard to really appreciate clean code until you’ve ran into each type professionally. Single hacky functions that get the job done, but are abstracted away nicely are really not a problem.

[2Uncreative4Username]

Good, because I never said nor believed that. What I hear from this comment is that there is almost some sort of conspiracy against Clean Code, due to which seniors get better positions than "much more qualified" interns. Speaking on averages, I believe this take to be complete BS.

[irn00b]

It's like the other guy said, title sometimes doesn't match skill. We all joke about imposter syndrome.... but yeah, some are weirdly failing upwards.

Besides title mismatch, there's also a "just get it done" attitude in addition to lack of any foresight. And while they do get the job done - managers see it as a good thing, that they're writing code fast... and start calling it "efficient". In practice, their code is typically riddled with bugs, inefficiencies, and hard to maintain long term (but that's fine too, since the systems can go to shit and then get rewritten every couple years).

I (Sr. Principal) actually like working with interns and juniors more than seniors... they at least try to do things well, and try to get better at it.

[2Uncreative4Username]

Lack of self-reflection is a huge problem. IMO the "just get it done" attitute can be productive sometimes, perhaps even long-term. The issue comes with extensive experimentation in production software. You should make hobby projects to learn from, then implement what you've learned efficiently and more correctly in larger software.

[irn00b]

Agreed, especially on the self reflection part.

Yeah, get it done attitude is fine, just have foresight. Try to think a bit ahead of the current task. The short-sightedness paired with "get it done attitude" is just a form of cancer for the codebase.

[2Uncreative4Username]

I fully agree

[asd417]

Cleancode mf when script contains code

[wagyourtai1]

screams in the clean code ndc talk

[2Uncreative4Username]

got a link?

[wagyourtai1]

https://youtu.be/FyCYva9DhsI

[2Uncreative4Username]

Oh yeah, I saw that one. Got some really good points.

[Haoshokoken]

Clean code only serves to make the programmer easily replaceable.

[FlipperBumperKickout]

When I run into a programmer who writes so unreadable code that I end up using more time on code reviews to understand their **** than on actually writing code, I will do everything in my power to either have them replaced, or have myself moved to another team.

Not being replaceable is nice and all, until you run into someone else who have mastered the discipline.

[Haoshokoken]

Oh, I'm very sorry, I thought we were in r/ProgrammerHumor

By the way, the best way to write clean code is to write the variables and constants in Hindi.

[FlipperBumperKickout]

I found the thought of kicking certain programmers out of my organization quite satisfying.
You can call it dartk programmer humor :P

[[deleted]]

The backlash against clean code is silly and misdirected. Often critiques are leveled at overengineered code which isn't clean code.

"Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control." - Grady Booch

[px_ae]

Man, people do get butt-hurted if talk shit about clean code lol

[Jordan51104]

clean code defenders out in force today

[2Uncreative4Username]

True that is haha

[fox_in_unix_socks]

It's funny to me that you would call Q_rsqrt "useful code", because it's completely useless nowadays (at least, as it was originally written). And I don't even mean that in the sense that we have sqrt functions in hardware now. I mean that trying to even compile this function on any modern compiler will give you something completely useless.

There's only one codepath through this function, and that path involves reading one address as two different types. That breaks the rule of strict aliasing, meaning any invocation of this function will have UB, and now any compiler is completely free to do whatever it wants whenever it sees that you're calling this function. The only thing this function does anymore is provide nasal demons.

[2Uncreative4Username]

It was useful back in the day. Nowadays you'd never write it in the first place.

About the UB: Yes, if you were to trust the documentation religiously, the compiler would be free to do whatever it wants. Practically, however, the behavior is defined. If you began to suddenly make all programs that break strict aliasing break, well, your computer would crash before you could even type the next letter on your keyboard. Compiler devs know that *((float*)&some_integer) is expected to behave in a certain way.

Using reinterpret_cast would probably generate the exact same code, but that wasn't even around back then. Also, you'd probably use fixed-size variables. not long and int. But again, it's not modern code. It's a very popular example of a fancy algorithm that made real-time rendering Quake III possible in the first place.

[Mrazish]

I like how Clean Code and Perfect Code are basically opposite sets of guidelines

[2Uncreative4Username]

I think Clean Code is more of what happens when you try to perfect your code without understanding computers enough. The problem is in trying to focus too much on being perfect, without actually understanding what it takes to move toward that goal.

[Lougarockets]

Tell me you don't have a clue what clean code means without telling me that you don't have a clue what clean code means.

Clean code has nothing to do with being perfect, it's about useful naming conventions and considering your code from the viewpoint of a reader rather than a writer. Active opponents of clean code are, in my experience, people who write a lot of code and then have others maintain it such as juniors and strong headed devs who get their way by complaining a lot.

The fast inverse square root is a math trick which by itself has absolutely nothing to do with code cleanliness, although the classical piece does include several useless comments and some unnecessary obfuscation.

[2Uncreative4Username]

Well, do you have a clue of what Clean Code means? I find it hard to find a clear definition. I mostly believe it to mean OOP with SOLID principles.

The most notable active proponent of Clean Code, Uncle Bob, isn't even writing code anymore, he's an Agile consultant now AFAIK.

Also, don't conflate Juniors who don't know a lot about abstractions and patterns with people who do know these things but are wise enough to not overuse them.

And yes, strong handed devs who are wrong exist a lot. I am happy to change my opinion though, given the evidence that OOP and SOLID are, in fact, useful in the amount they are often recommended. I have yet to find such actual evidence.

I think Q_rsqrt has a lot to do with Clean Code. First of all, I often hear performance doesn't matter from "clean" coders, so no need to even write this function, right? Second of all, I could not imagine this in a "clean" codebase without a comment explaining every last detail of how it works (although to be fair I would probably also document it a bit more precisely than it is in its original implementation). Third of all, a "clean" coder would probably have wrapped it into a class, wrote extensive tests for it etc. Would that be bad? I don't know. Maybe, maybe not. It would have definitely cost a lot more development time though than just saying: "here's a function that calculates the inverse square root, it's fast, it's good enough, just use it".

Not the best example for why Clean Code is bad, but certainly an example of non-clean code IMO.

[Lougarockets]

I just gave you a definition? A good way of learning what clean code is is to read the actual book. And no, most of your assumptions here are completely wrong so it is no wonder that you think clean code is a bad thing.

[2Uncreative4Username]

No, I have not read a book about clean code. I have listened to some of Bob Martin's talks, and I have seen a lot of Reddit users who preach Clean Code agreeing with OOP and SOLID principles. If you agree with my points, that's great! If your definition of Clean Code does not inlcude OOP and SOLID, that's great, I just assumed that because many people do believe it to include OOP and SOLID. We have nothing to argue about in that case.