95% of time a restricted set of possibilities is all you need and is 10x easier to mainain that abstract classes or interfaces.
Sum types solve 95% of use cases for inheritance better than inheritance. It blows it out of the water performance wise, in the ease of initial implementation and in long term maintainability.
Extremely rarely do you actually need a completely abstract and open interface for which there could be numerous implementations.
And when you actually need that, delegates and/or function pointers provide better performance and dev experience for that.
What is funny about Clean Code is that everyone is praising it, but no one has read it, nor follow it. And when you ask what you can learn from it people generally say: >Good names >Short functions
Without going into specifics of what either of these mean. And honestly, good names? Do you really need a fat homosexual to tell you not to name a function foo, or a variable x? Isn't this something that everyone figures out by themselves?
I think the best cure against the Clean Code madness is to actually read Clean Code, and specifically Martins own code written in his own style. It is dogshit.
As someone that has actually read it. Yeah there's some generally good advice in there.
It's just also mixed with the cargo cult stuff that he and others just assumed to be good.
I actually followed the "make functions as small as possible" for quite some time, before I realized how fricking ridiculous that idea is.
>Do you really need a fat homosexual to tell you not to name a function foo, or a variable x? Isn't this something that everyone figures out by themselves?
Some people need everything spelled out for them. Some people need to be presented with an idea before they will consider it. People like to assume that other people think like they do, but that is not the case.
2 months ago
Anonymous
I honestly think the standard and expectations should be so high that we don’t hire those so called ”devs”. And yes, there are some good common sense advice in there, but the main problem is that it gets overshadowed by the bad and self contradicting advice.
The perfect function according to C. Bob is >max four lines long >no input parameters >zero side effects
Which makes sense because Bobson is also useless. But even he realizes that such a function can’t do anything, so one advice has to go when he writes his code. And he chose to break the only good advice: no side effects. His code is nothing but side effects, in fact all of his logic is in fricking side effects
2 months ago
Anonymous
>I honestly think the standard and expectations should be so high that we don’t hire those so called ”devs”
Even if we cut off a huge part of the rotten flesh we don't really have enough people to do that. I think we just need to move away from misguided principles and people will become better as a result. A big part of it is the really bad practices we instill in developers.
It sucks. Robert Martin is a fraud and doesn't know how to code. I'm actually writing a lecture at work that I will present sometime during spring where I basically tear Bob's butthole open and turn it inside out for all to see.
No one ever saw anything he actually made, but he has a consulting firm, so one can expect his guidelines to be useful in maintaining it-based rentseeking
>Have problem and need a competent developer >Get in contact with Uncle Bob >Or at least think you do. >Call his number. A receptionist answers >Hi, may I speak to Bobert Martin, please? >Oh, he doesn’t work here. We’re just a shell company. Let me redirect you. >Get put on hold indefenitely whilst the receptionist desperately tries to find the number in the phonebook >Hang up and decide to instead decide to visit his office >Roll up to a big fricking factory that seems to be producing factories >Weird, is this really the right place? >Shrug and walk in through the door >Wait, why am I still outside? >See new factory in front of me, walk into the reception. >Get directed to a new room, it’s another reception >the new receptionist points me towards a meeting room right next to a door to a restroom >Wall in and see that both doors lead to the same room >Fat frick is in the room, walks out one door and in through the restroom door and proceeds to take a big shit on the floor before walking back out again and in through the first door >Suddenly a switch is activated and a cup of coffee pops out from a cupboard. The fat frick grabs it and pours out the contents in the plants which triggers a light to blink in the other end of a room >Suddenly a siren begins wailing, a pajeet hops in from a window and turns the siren off. >This causes the floor to collapse and I’m suddenly in front of Bobby C. >WTF just happened? >Hi, what can I do you for? He asks >Before I can answer a loose spring pops out from his head and his arms fall off >Turns out it’s a dummy
Mostly good, I don't adhere to "Clean Code" because I'm lazy but I can see the benefits. The part about small functions is pure shit though and early abstractions are never good.
I know this is bait, but the #1 thing that's bad about clean code is its underlying mentality. Clean code is all about the programmer, not the program. When I code, all I care about is the program, not my experience making it. When I use software, I don't give a frick about the experience of those behind it. If it works, I'll use it. You can argue that clean code helps to make better software, but that's provably false for everything is shit these days. Ultimately it's a skill issue.
Write code that's good for the hardware and experience of the user only.
I don't think you're wrong that clean codes subtext is more important than its actual content but you're wrong about its subtext. Clean code is about how programmers can use only code to communicate with one another. The main objective being fungibility, aka replace-ability but the bright side is less contact with my peers, while I still have a job.
The book "Clean Code" gives bad to mediocre advice
Writing your code to be easy to understand and debug and modify is an incredibly important skill
I'm not a Caseyologist but I get the impression that he only understands his own immediate context and just assumes the whole world works like that, not worth your attention
Never read it, I don't need it. Clean code is functional code. Comments solve whatever else isn't already covered by the clarity of FP (like why there's a random delayer in the middle of the program)
What is funny about Clean Code is that everyone is praising it, but no one has read it, nor follow it. And when you ask what you can learn from it people generally say: >Good names >Short functions
Without going into specifics of what either of these mean. And honestly, good names? Do you really need a fat homosexual to tell you not to name a function foo, or a variable x? Isn't this something that everyone figures out by themselves?
I think the best cure against the Clean Code madness is to actually read Clean Code, and specifically Martins own code written in his own style. It is dogshit.
Good post.
Threadly reminder that some of Uncle Bob's own examples of refactoring on real world code introduce serious bugs and almost nobody spots them because of the way everything gets obfuscated under 10 layers of private functions operating almost exclusively via side effects.
And nowadays enteprise Black folk just take a random noun and slap it on a variable, without regards for the meaning of either, because it's "descriptive" therefore good.
I agree that simplicity is beautiful. I also always look for the root cause of bugs, never "patch" bugs somewhere half-way in the chain of events unless you're making some temporary hotfix. Consistent code is also good.
I mean, I agree with a lot of it, but certainly not a fan of all of it. For example, my experience with dependency injection is mostly .NET Core code, I think dependency injection is fricking stupid honestly and it complicates the program instead of simplifying it.
DI can make sense for projects with tons of generic components seeing a lot of reuse (ex. you have one messageProcessor<T> with a dozen concrete instances), but I agree that it's overused to the point of being a meme.
One of the homosexual TLs at work has spent weeks on DI wankery for a tool that's supposed to automate a simple update on ten database rows a day, tops.
Doesn't help that his team is full of juniors and pajeets, so they all think he's hot shit.
>And nowadays enteprise Black folk just take a random noun and slap it on a variable, without regards for the meaning of either, because it's "descriptive" therefore good.
strawman
2 months ago
Anonymous
>s-strawman!
Literally something I see at work every day.
var path, it's the filename without extension.
var email, it's the username.
var dateString, it's not a date nor a string.
2 months ago
Anonymous
nta but tbtbh anon you need to go and work for a different company
that sounds fricking horrible
I read it a while ago but the only thing I remember is that 'clean code' should consist of 1-4 line functions with descriptive names (at least I think it's from the clean code book). imo this makes it hard to understand what's going on but at the same time you can't have 10 minimum wage 'jeets working on the same file at the same time otherwise.
>And honestly, good names? Do you really need a fat homosexual to tell you not to name a function foo, or a variable x? Isn't this something that everyone figures out by themselves?
extreme shorthanding and memorizing what each thing does is common in C and C++, where people also still stick to the "no more than 80 characters per line" rule religiously , but that what's a good C practice won't be a good Java practice
Integer.parseInt(s) is more descriptive and easier to just read and correctly assume what it does than itoa(s)
also, "x" is a perfectly fine name in certain cases, just don't make its scope too large
>extreme shorthanding and memorizing what each thing does is common in C and C++, where people also still stick to the "no more than 80 characters per line" rule religiously
What the frick are you talking about? Yes, some c and c++ functions from the standard library are opaque because they were written decades ago and we had other limitations on HW. But that isn’t something common with C or C++ devs today.
it still used to be a principle that was being taught last time I had to touch C
and "being written decades ago" doesn't change the fact that it's still unchanged today. or have itoa() and atoi() been deprecated for something more readable?
in any case, even if C people learned to write longer lines, there's probably a lot of other things that would be a good practice in C but a bad practice in Java, and vice versa
2 months ago
Anonymous
Then you had shit teachers, grandpa. What would be the point in rewriting atoi just to give it a new name? Better to ensure that new code is more descriptive
Naming things like that is a learned behavior. All the people who need to be told not to name things like "itoa" are all annoying nocoder IQfy cniles who got memed into not learning something useful like Python.
I don't need a god damn book to know clean code, I have my own guidelines >descriptive names
Unless it's a throwaway variable everything has a descriptive name, I make use singular and plural forms, same for functions/structs/classes >short functions
If a function is not fitting in one screen I'm doing too much in it so I split it. Usually when a function does too much then it can't have a descriptive name so rule 1 actually guides me in this one, e.g. if a split function can't have a descriptive name then it shouldn't have been split so I join it again >no comments
My code should be effortless to read like prose. And then no comments are needed, everything describes itself. Applying the above 2 rules leads to a huge reduction of comments and self documenting code >don't sweat it
Working code is more important than clean code. I won't follow any rule religiously if it's going to shit on my project.
Hard disagree on both clean code and short functions. Bob C. Bobson has basically co-opted the term so if you say ”I do clean code”, even if you don’t mean it people will assume that your code has Robbies seal of approval. In the absolute worst case you are actually good and therefore unintentionally lead poor juniors down the path of ”Clean Code”-code because they want to be like you. So they buy his book.
And regarding function length, they should be as long as they need to be. If you have a long ass function that needs to perform many steps to do one thing you don’t actually have a function that does ”too many things”, just a function that does one big thing. Splitting this function into smaller functions doesn’t in any way reduce the amount of steps you need to do, or reduce the smoking of code you need to keep in your head. It only makes the function more annoying to read and reason about. We can all agree that functions shouldn’t be longer than necessary, but assigning arbitrary metrics to determine this only shoots yourself in the foot.
Read my number 2 rule carefully. Naming guides what I should do. If by splitting a big ass function with descriptive name in 4 small functions with non descriptive names that now have to have comments to remember what they do then I don't split. But usually without even consciously trying I end up with small functions with descriptive names that do something concrete and atomic.
2 months ago
Anonymous
You can split a big function into smaller functions that do something concrete, with concise names, and still end up with functions that get called only once and fulfill no purpose on their own. I get what you are doing because I do something similar. When I write functions I start with just a heading and input/output. And may write several of these to understand how I think I want to put everything together. Then I actually code. And sometimes code needs to be repeated and gets put in its own function (if it makes sense).
I agree that simplicity is beautiful. I also always look for the root cause of bugs, never "patch" bugs somewhere half-way in the chain of events unless you're making some temporary hotfix. Consistent code is also good.
I mean, I agree with a lot of it, but certainly not a fan of all of it. For example, my experience with dependency injection is mostly .NET Core code, I think dependency injection is fricking stupid honestly and it complicates the program instead of simplifying it.
I'm like this homosexual. I talk a lot about how software should be written and I keep pointing out mistakes when oither people write something. I regurgitate talking points I find on Hackernews and other places and people think I'm such a fricking expert at everything.
I can write some spaghetti piece of shit and I actually I know frick all but I am charging the client a good amount and only a fraction of it actually goes to the developer.
If you're in the software business and you're the one writing the code, you're a fricking moron.
Necessary evil for sufficiently large projects with multiple chefs in the kitchen. The alternative - letting everyone freestyle their shit and then expecting everyone to step in and debug what amounts to schizo bullshit in an emergency - is moronic.
You need to establish house rules.
You need to test your code.
Your code should have minimal side effects and be maximally deterministic.
>Necessary evil for sufficiently large projects
Hell no it isn't. What's easier to debug;
A subroutine with excessive amounts of masturbatory abstraction where each of those are split into individual files or just HAVING THE FRICKING CODE THERE.
The answer depends on number of side effects. A single massive function with branching conditional, nested functions and a shitload of shared state is going to be a pain in the ass to deal with in a sufficiently complex codebase where things happen asynchronously. And even for synchronous code, writing massive conflated shitpieces results in shit that's going to be harder to refactor later.
>Your code should have minimal side effects
So, the opposite of Uncle Bob's refactoring examples.
Oh yeah Uncle Bob's examples are dogshit but the concepts he's talking about are correct.
>Your code should have minimal side effects
that by necessity means that your code cannot be object oriented because by design OO works exclusively through side effects.
Minimize side effects, not remove them entirely. Smalltalk style message passing is the right way to OO if you must OO.
>A single massive function with branching conditional, nested functions and a shitload of shared state is going to be a pain in the ass to deal
I mean no shit I'm not saying you start writing your code like a moron
2 months ago
Anonymous
Except that's usually exactly what happens when people say frick clean code and you have several dozen different people working on the same project. Each one introduces their special global variables for their special functions that compose or inherit from other people's special functions and global variables.
Nobody is testing shit because its become too massive of a task to think of all the different execution paths that the program could take.
It's tolerable at first, silently spirals out of control, and then suddenly you're stuck working 80 hour work weeks hunting down heisenbugs and debugging race conditions silently introduced by code merged in from some guy that left the team half a year ago.
2 months ago
Anonymous
What you're proposing is that there are zero coding practices at all. It isn't really about clean code at this point.
2 months ago
Anonymous
Slippery slope fallacy isn't a fallacy when it comes to this stuff.
2 months ago
Anonymous
You can still enforce practices without having to suck the tit of excessive polymorphism, abstraction, dry etc. No one is advocating for people to start writing like webjeets from the 2000s.
2 months ago
Anonymous
What you're proposing is that there are zero coding practices at all. It isn't really about clean code at this point.
2 months ago
Anonymous
>No one is advocating for people to start writing like webjeets from the 2000s.
Nobody advocates for living in a crackhouse either, but it still happens to people because of the choices they make.
2 months ago
Anonymous
Are you saying that modern software companies are any different from people huffing abstraction and polymorphism crack smoke? Look at the absolutely moronic state of Microsoft.
2 months ago
Anonymous
The reality is that we went down the "clean code" slope and it has seriously harmed software as a result. This isn't even a "oh but z might happen because a", it did happen, it's real. Maybe it's time to look at it from a different perspective.
Maybe it sucks.
2 months ago
Anonymous
>we went down the "clean code" slope
When? In most places I've only seen people fighting it and still using mutable global state alongside their weekly alpha and omega functions that they need the whole team to help them debug every weekend when prod is shitting itself.
Places that are actually doing CC are far and few between, or you have people claiming they're doing CC when they're really doing pic related and just abstracting things into batshit insane mode instead of doing the core stuff such as reducing mutability and shared state, composition over inheritance, doing one thing and doing it well, etc.
No, it's stupid having everything out of context even in an IDE. I have to question whether or not you've even tried the alternative to see for yourself.
2 months ago
Anonymous
>having everything out of context
the functions define the context
having more small functions makes for smaller, more precise context in each
surely you're not so mentally challenged as to not being able to comprehend anything but flat global state?
2 months ago
Anonymous
I'm not in particular arguing against functions though, like I said earlier. You're taking in this in the context that everyone should just write moronic code instead, which is not what Casey or anyone else is arguing for. It's just a blatant misrepresentation.
2 months ago
Anonymous
>You're taking in this in the context that everyone should just write moronic code instead, which is not what Casey or anyone else is arguing for.
Have you seen Casey’s code?
what is with everyone idolizing opinions of game devs out of all people. they never wrote anything that needs to keep the world running.
He isn’t a gamedev.
2 months ago
Anonymous
>Have you seen Casey’s code?
I'm not shilling this homosexual. But that code makes sense to him. If you don't like it, you write it your way, make it public and lets see if we can read it all and conclude: yes this is "clean" code.
You fricking dumbass.
2 months ago
Anonymous
Lets see anon's code.
2 months ago
Anonymous
2 months ago
Anonymous
He killed BILLIONS of sóydevs
2 months ago
Anonymous
Maybe he did offend a lot of programmers concerned with everything except for programming, but his advice is meaningless unless you write programs with systems programming languages. The fact is that the vast majority of popular programming languages have so much unnecessary runtime overhead, that what you could gain by writing simple code is completely offset by shit efficiency of the managed language. You can extract single-digit percentage performance improvement by writing simple linear code instead of OOP monstrosities, but it's just not worth it most of the time.
Look at Python - it's at the level of excruciatingly slow where you can exclusively `raise` exceptions instead of `return`ing values for the convenience of try-except pattern matching on different cases, and it's just as slow as a simple if-else block.
2 months ago
Anonymous
I would say his advice is stupid because he isn't operating in the ballpark of performance he is complaining about. b***hing about virtual and cache/prediction optimization is meaningless when what he really b***hes about is precisely someone writing in Java, or worse Javascript. Frick in the first place a lot of 2000-2010 were still firmly written in the OOP model and he will bring a program from basically that time and b***h how much the performance degraded compared to some contemporary alternative.
2 months ago
Anonymous
java isn't inherently slow, but i've used some "enterprise" java software (some apache data software) and it is slow and bloated
2 months ago
Anonymous
>java isn't inherently slow,
It's about as inherently slow as virtual functions or OOP code in general is, unless you're fighting the language itself to get something optimized but I am kind of green in the area of performant Java code and how hard can you make something utilizing SIMD or work on data locality. Which is kinda what Casey is scrutinizing, where his silver bullet for non performant software is just the bad OOP, never mind when fricking windows has always been based on OOP and virtual tables in win API. >but i've used some "enterprise" java software (some apache data software) and it is slow and bloated
Yeah you can make just about anything unbearably slow by doing stupid things, but in general you can avoid doing those stupid things in any paradigm.
2 months ago
Anonymous
in the first few minutes he literally admits the biggest problem with clean code. It's subjective and means absolutely nothing.
2 months ago
Anonymous
why is this homosexual using C++? Pretty sure the boomer galaxy pic clean code book is java jeet shit.
comparing OpenJDK's compiler to any C++ compiler is like apples and oranges.
2 months ago
Anonymous
>Smaller
No, because context in one function is now suddenly depending on context somewhere else to make sense >More precise
Also no for a similar reason
We can both agree that functions should have a purpose, yeah? Functions should do one thing, yeah? Clean code creates functions that do nothing, and to get this ”one thing” you have to sum up many functions that call each other. And if you follow Bobby C Dobby’s advice they also operate exclusively through side effects
2 months ago
Anonymous
>No, because context in one function is now suddenly depending on context somewhere else to make sense
if your code ends up with dependencies like that, it's solely your fault for writing shit code
i'm actually having a very hard time imagining how do you even frick up something as simple as an "extract method" refactoring. i've seen it happen, but in every case it's always been the author being absolute garbage at writing code anyway
>Clean code creates functions that do nothing
no, again, it's you being bad at picking out things to put in a separate function
even if it's some private method that is being used only once, it can still create a narrower context/scope for the operation that specific method does, so the method that calls it can have a smaller, cleaner context. whether that actually happens or not, entirely depends on your abilities to write code
2 months ago
Anonymous
>if your code ends up with dependencies like that, it's solely your fault for writing clean code
fify
>Your code should have minimal side effects
that by necessity means that your code cannot be object oriented because by design OO works exclusively through side effects.
>by design OO works exclusively through side effects
No it doesn't, wtf are you smoking?
You can easily write OO code that works just using return values. >inb4 constructors are side effects
Why would you even consider OOP in the first place if your program has little to no mutable state? Isn't one of the OOP things people do is "protect" or "encapsulate" state? Sure, you can do it, but what you are doing is no longer OOP, it's pure functional programming with weird closure definitions.
2 months ago
Anonymous
"little" and "no" mutable state can make a world of difference
2 months ago
Anonymous
NTA and also dislike OOP but I wouldn’t equate changing state with side effects. If it is explicitly clear from your functions that states will change then you can’t really call it a side effect. It is just an effect.
2 months ago
Anonymous
As an example, take shared pointers in c++. Adding a reference increases the ref counter by 1. This is a change of state. It is also a state change that you as user have no control over. But is it a side effect?
Or say that you have some sort of dynamic list or whatevs, and that has a counter that keeps track of the number of elements. You insert an element. Is the counter update a side effect?
2 months ago
Anonymous
Changing state is literally the definition of a side effect.
This isn't a vauge concept.
You can have intentional side-effects, but they're still side-effects. It's not necessarily a value judgement.
if you primarily think of subroutines as functions, a.k.a things that produce output (return values) based on their input (arguments) then anything you can observe as a result of having called them are side effects, or indirect output.
You can infact build archirecture around pure functions and build big complex systems around that idea, and only allow for state changes/side-effects at the edge of your system. Not only is this possible but works remarkably well for way more use cases than people would assume.
2 months ago
Anonymous
I see. Then Clean Code makes even less sense, as well as the general hostility against side effects. They are just a tool like anything else
2 months ago
Anonymous
Sorry bro, hostility against side effects makes perfect sense for anyone who has found themselves debugging legacy code.
Side effects seem fine when you're building your mental model alongside the creation of a greenfield project with a puny LOC total. They are pure hell when the codebase is 100K+ LOC and 50+ devs have snowballed more state and bugs back and forth than a San Franciscan polycule.
2 months ago
Anonymous
I’ve debugged plenty of legacy code professionally. I know the dangers. But I also see the benefits of modifying state. As everything else you need to be smart about it.
2 months ago
Anonymous
This man knows. Inheritance + side effects + event handlers is a nightmare to maintain. I got so fed up I moved fully over to immutable state with pure functions, and I've not had any problems since then. Everyone at my new job loves my code.
2 months ago
Anonymous
what if internal changes of state do not affect any results produced by the object?
2 months ago
Anonymous
then you're literally just wasting CPU cycles.
literally why bother
2 months ago
Anonymous
NTA but why would anyone do that? It would be better to just have everything in a function instead in that case.
2 months ago
Anonymous
Then it's still a side effect because a poor junior can come along one day amd be tasked with adding some business logic relying on that state without zero awareness aware of your hidden frickaroo logic spinning up race conditions under the hood. Great idea for job security, though.
2 months ago
Anonymous
I forgot a very important "else" in that last line.
anything else, besides a functions direct output (return value), that you can observe as result of having called it are side effects / indirect output.
2 months ago
Anonymous
I use out parameters in C++ all the time. Not because I think it is good, but because the alternative of using tupels and pairs is so much worse and less performant. Sure, the performance hit is really minimal, but I mean, why? I’d rather work directly on the objects I have instead of making a fricking copy and tossing the original
2 months ago
Anonymous
Well, out-parameters are at least explicit.
at least the caller has complete control over where those side effects get placed.
How ergonomic it is to use direct output instead is dependend on the language I think.
If you can't easily define on the fly data-shapes to describe exactly what you wanna return then thats on the language.
Sorry bro, hostility against side effects makes perfect sense for anyone who has found themselves debugging legacy code.
Side effects seem fine when you're building your mental model alongside the creation of a greenfield project with a puny LOC total. They are pure hell when the codebase is 100K+ LOC and 50+ devs have snowballed more state and bugs back and forth than a San Franciscan polycule.
this. large code bases with heavy side-effect driven behavior can often turn into rube-goldberg like clusterfricks with totally inscrutible and confusing design.
2 months ago
Anonymous
It is extremely easy in C++ actually, just annoying. I can on the fly make a tuple of say an int, a string and a struct F through std::tuple<int,std::string,F> data = std::make_tuple(i,s,f);
And to access say the first element
int j = std::get<0>(data);
Easy, annoying, boring
2 months ago
Anonymous
yeah thats exactly my point
having to do this: >std::tuple<int,std::string,F> data = std::make_tuple(i,s,f);
when you wanna return an int a string and some third thing is way too much of a hassle
no wonder you woundn't want to do that.
especially if you have to write out that generic clusterfrick of a type definition multiple times,
which I assume you have to.
std::get<0>(data)
also is way to fricking moronic and cryptic for what it accomplishes.
2 months ago
Anonymous
I'm in a love/hate relationship with C++. I love the language, but I don't love how it treats me. But everytime I try to leave it it always comes up and starts to treat me right, only to later hit me. Sometimes I wear sunglasses so that others can't see my black eyes.
2 months ago
Anonymous
try using cppfront then, all the good of semantics of C++ without the random gotchas of an older syntax.
According to OO theory, individual objects interact with each other through messages, which in languages like java and C++ generally translates to method calls.
Objects are supposed to be opaque and not have access to data of other objects.
Thing A sends a message to Thing B and as a result, Thing B might send various other messages around and more importantly modify its internal state that no one else has access to.
I don't know what you would call that but that seems to me like a system that exclusively works through side effects.
In true OO, objects shouldn't even be understood as data-types, since you're no supposed to have access to any data.
They're unknowable things that you can only interact with through their specific interface, a.k.a the messages that they accept.
I think this goes without saying but this is obviously a horrible, disasterous, mind numbingly awufl idea.
2 months ago
Anonymous
>Thing A sends a message to Thing B and as a result, Thing B might send various other messages around and more importantly modify its internal state that no one else has access to.
now dress that into a concrete example rather than meaningless abstract "A, B, C" entities
pretty sure you either won't be able to make an example where your scenario fits and makes sense, or your example will have its design flaws very visible and just asking for getting refactored
2 months ago
Anonymous
I am not proposing to build systems like that.
That is obviously moronic.
It's just that this idea is the core of OO.
Which is why OO is also moronic.
2 months ago
Anonymous
>I am not proposing to build systems like that. >That is obviously moronic.
i.e. strawman
you make moronic designs, then blame OO for being moronic
>It's just that this idea is the core of OO.
except it's not
2 months ago
Anonymous
Sir! Why are you lying sir? Why do you talk so much incorrect things you b***h bastard?
2 months ago
Anonymous
OO means "object oriented", not "mutable state oriented".
A shitload of business logic can (thankfully) be boiled down to the following: >parse some data with object A to create object B >feed object B to object C, which does some processing and spits out the result as object D >serialize object D to database/filesystem/whatever by using object E
Zero mutable state required or even desired, every object except B and D can be a static class even if management Black folk prefer singletons created by bloated IoC systems for some ungodly reason.
>in true OO, objects shouldn't even be understood as data-types
Says who, some functionalgay?
Learn what a Data Transfer Object is.
2 months ago
Anonymous
Frick, forgot to tag
Why would you even consider OOP in the first place if your program has little to no mutable state? Isn't one of the OOP things people do is "protect" or "encapsulate" state? Sure, you can do it, but what you are doing is no longer OOP, it's pure functional programming with weird closure definitions.
also yes, constructors definitely are side-effects, and encourage programming styles that rely on side-effects.
They're absolutely awful. Them causing heap allocations is the less interesting part, but the way they are implemented in popular languages is a plauge.
Abstraction doesn't exist in software. It simply materializes components and systems out of innate memory, much like life materializes out of innate matter, in more and more complex ways. If you have a factory that makes factories that's because there is an actual need to do this, but your mind is simply not powerful enough to understand these virtual systems beyond "array and ints" gruggery
Muratori is based.
Clean code cultists are moronic.
You should only make your code clean when there is a clear advantage towards organization and maintainability.
You shouldn't worship it like some religious universal truth or some shit.
Just be high IQ and your code will look nice, if you are a dumb room temperature IQ your code will be garbage regardless of the "principles" you follow.
How do you cope with programming in a dogshit language like Python? Every stupid library function is throwing 17 different exceptions, everything is polluted with try except except finally raise ShitError from PissError. Look at the top used libraries and frameworks. They all reuse the same exceptions for both trivial local control flow, and global "error handling". Why are these people allowed to write software?
No one is advocating unnecessarily "dirty code". The problem is that some moronic hack established a set of dumb standards promising simple answers to complex problems, and it was accepted as gospel by clueless juniors (I used to be among them).
"The Elements of Programming Style"
And
"K&R C Programming Language"
Is all you'll ever need, anything else is troony/Corporate shit.
If with those your code is still shit go become a webdev or something.
because system programming is 100x easier than business programming.
it's easier to optimize a 10k C code by hand. it's fricking impossible to do the same with a massive backed that orchestrates thousands of objects.
it's even impossible to reason about massive backend behavior and keep in a head all its routines and corner cases like you would with your average C driver.
that's why safe and robust code is preferred over fragile performant code.
>hmmph, tell me what to do to make my life easier, will you? >i'm going to make my code deliberately bad to spite you!
I'm not going to @ all of you but this is peak IQfy chuuni/ contrarianism. You won't even follow through with it, of course you'll try to write good code.
After reading a bunch of articles with negative hackernews reception, and watching a few contrarian israelitetube videos on this topic, i sat down and started programming "like a moron". The experience was eye opening. It turns out that simple and stupid procedural programming is not only significantly more productive, but the end result is more correct.
Here is how you should program:
1. Write a sizable chunk that does what it should do.
2. Replace repeated code blocks with function calls.
3. Repeat until the program is finished.
If you write in a fancy language with cool features like RAII and exceptions, don't bother. Just use if-else statements. I also find that a single return statement at the end of the function leads to better design.
i'm so sick of all this dependency neo-drama. it used to be that you could make an assessment on whether to adopt a package or stack dependency based solely on its technical merits / trade-offs. but since pozzed, golemized millennials took over software, every possible software dependency you might need for your project now carries with it a bunch of potential troony marxist loxist political drama. i've used modern langs / platforms to build my software to peak abstraction heights. and while it was really nice in many ways, i don't know if it's worth all the drama of sucking in layers and layers and packages and packages of dependencies that you can only get support for via their 'communities' if you submit to the #currentthing ~~*troony*~~ dick. imagine considering a dependency on a package then looking for their support community and finding it plastered with pedo rainbow colors.
so i'm going back to structs and arrays. every language supports these, all the way back to C. I will write every last goddamn line of code in C if I have to in order to assert my self-ownership in this dying techno gay hellscape. And I can use these technique in any language and therefore any corporation that I might need to merc for for shekels.
you can do everything you need with structs and global arrays. and goddamn 95% of the time at least, it will be soooo much simpler not to mention performant. if we really need a kernel-style abstraction layer, C has static declarators that hide visibility among translation units (hopefully I got the verbiage right, correct me if I'm wrong).
We as programmers have everything we need, and we've had it for decades. And now we realize the true cost of our unnecessary dependencies and their israelited censorship industrial complex by way of 'codes of coducts' and ~~*sensitivity standards*~~.
"Clean Code" is only clean if it's make things more readable.
If it's not making things more readable, and instead it becomes a Pan's labyrinth then it's akin to liquid diarrhea being sprayed in random files instead of where it frickign belongs.
And clean code shold never be a deciding factor in critical sections of code that are executed many times a second.
And I mean in the case that, pursuing "clean code" makes it impossible to optimize.
>And I mean in the case that, pursuing "clean code" makes it impossible to optimize.
ironically, clean code makes it easier to optimize code because it's easier to tell what the code is doing in the first place
"optimized" code is often unreadable and almost always unmodifiable
>And clean code shold never be a deciding factor in critical sections of code that are executed many times a second.
you make it sound like critical sections are 90% of code in a codebase
you can still have general clean code with fast critical sections
You don't do optimizations because they look pretty, you do because it's necessary.
Optimizing something that has been abstracted too much that you no longer have a grasp of the data structure, is as enjoyable as taking a dive into a meat grinder.
If you know that something will need optimization, perhaps it's better to avoid abstracting that code too much.
And no, not I'm not making it sound like it's 90%, I did specify I'm talking about code executed many times a second. Most things don't matter, but rendering, game loops, and other stuff that fall into this condition is always worth optimizing.
>You don't do optimizations because they look pretty, you do because it's necessary.
ideally, yes; in practice, people who are obsessed with optimizations and performance will push to "optimize" everything, preemptively or otherwise, and always sacrifice maintainability
>Optimizing something that has been abstracted too much that you no longer have a grasp of the data structure, is as enjoyable as taking a dive into a meat grinder.
you equate clean code to "abstracted too much"
- you can do clean code without going overboard with abstractions
- you can have overly abstracted code that's not clean in any case
>Most things don't matter, but rendering, game loops, and other stuff that fall into this condition is always worth optimizing.
who even implies that kind of code is the target for clean code in the first place?
clean code is for high-level business logic and complex workflows inside enterprise software
2 months ago
Anonymous
Why are you arguing if we are in complete agreement?
"clean code" != clean code
My opinion is I hate opening up a program only to find a diarrhea swirl of endless files with layers and layers of dependency between each other so trying to understand flow control is impossible.
When you write code this way, I honestly don't see what's different about it from standard spaghetti. It's just as much a mess, except now instead of just the creator being the only one who knows what does what, NOW every fricking modulated part is only understood by ITS creator, so you just have this slodge pile of chunks that are designed to interact with each other, yet have no coherence or consistency with each other. "Clean Code" isn't clean code, it's crap enterprise code meant to work on a conveyer. And there is nothing wrong with generic variable identifiers. I don't need everything to be a fricking detailed description. X is an iterator, Y is some temporary value. It has no importance so it gets a generic name. Put 2 and 2 together. Tired of reading code that is more English than programming with the moronic cameCase identifiers that are longer than the rest of the statement.
>a failed gamedev with one unfinished project >knows what he is talking about
this is peak dunning kruger.
just because he knows some low level algorithms doesn't mean he is a good software designer.
design isn't about implementation, it's about how you stick different implementations together.
"Clean" Java code is more maintainable than typical cnile C/C++ diarrhea.
I too prefer four separate classes instead of a single switch statement.
you'd have to use switches everywhere in your code each time to differentiate
only during assignment
Okay but what if it's literally 15x faster.
What's the point of having fast code that is not going to be used by anyone?
what's the point of having slow code that is not going to be used by anyone?
in both circumstances it'd be way faster to just write the fast code
95% of time a restricted set of possibilities is all you need and is 10x easier to mainain that abstract classes or interfaces.
Sum types solve 95% of use cases for inheritance better than inheritance. It blows it out of the water performance wise, in the ease of initial implementation and in long term maintainability.
Extremely rarely do you actually need a completely abstract and open interface for which there could be numerous implementations.
And when you actually need that, delegates and/or function pointers provide better performance and dev experience for that.
As someone that has actually read it. Yeah there's some generally good advice in there.
It's just also mixed with the cargo cult stuff that he and others just assumed to be good.
I actually followed the "make functions as small as possible" for quite some time, before I realized how fricking ridiculous that idea is.
>Do you really need a fat homosexual to tell you not to name a function foo, or a variable x? Isn't this something that everyone figures out by themselves?
Some people need everything spelled out for them. Some people need to be presented with an idea before they will consider it. People like to assume that other people think like they do, but that is not the case.
I honestly think the standard and expectations should be so high that we don’t hire those so called ”devs”. And yes, there are some good common sense advice in there, but the main problem is that it gets overshadowed by the bad and self contradicting advice.
The perfect function according to C. Bob is
>max four lines long
>no input parameters
>zero side effects
Which makes sense because Bobson is also useless. But even he realizes that such a function can’t do anything, so one advice has to go when he writes his code. And he chose to break the only good advice: no side effects. His code is nothing but side effects, in fact all of his logic is in fricking side effects
>I honestly think the standard and expectations should be so high that we don’t hire those so called ”devs”
Even if we cut off a huge part of the rotten flesh we don't really have enough people to do that. I think we just need to move away from misguided principles and people will become better as a result. A big part of it is the really bad practices we instill in developers.
Nocoder detected
ya, unironically. if your language isn't shit it will monomorphize and inline statically knowable polymorphic calls anyhow.
Good morning, sir!
Four? Try 24 along with a dozen factory methods.
It sucks. Robert Martin is a fraud and doesn't know how to code. I'm actually writing a lecture at work that I will present sometime during spring where I basically tear Bob's butthole open and turn it inside out for all to see.
No one ever saw anything he actually made, but he has a consulting firm, so one can expect his guidelines to be useful in maintaining it-based rentseeking
>Have problem and need a competent developer
>Get in contact with Uncle Bob
>Or at least think you do.
>Call his number. A receptionist answers
>Hi, may I speak to Bobert Martin, please?
>Oh, he doesn’t work here. We’re just a shell company. Let me redirect you.
>Get put on hold indefenitely whilst the receptionist desperately tries to find the number in the phonebook
>Hang up and decide to instead decide to visit his office
>Roll up to a big fricking factory that seems to be producing factories
>Weird, is this really the right place?
>Shrug and walk in through the door
>Wait, why am I still outside?
>See new factory in front of me, walk into the reception.
>Get directed to a new room, it’s another reception
>the new receptionist points me towards a meeting room right next to a door to a restroom
>Wall in and see that both doors lead to the same room
>Fat frick is in the room, walks out one door and in through the restroom door and proceeds to take a big shit on the floor before walking back out again and in through the first door
>Suddenly a switch is activated and a cup of coffee pops out from a cupboard. The fat frick grabs it and pours out the contents in the plants which triggers a light to blink in the other end of a room
>Suddenly a siren begins wailing, a pajeet hops in from a window and turns the siren off.
>This causes the floor to collapse and I’m suddenly in front of Bobby C.
>WTF just happened?
>Hi, what can I do you for? He asks
>Before I can answer a loose spring pops out from his head and his arms fall off
>Turns out it’s a dummy
holy shit
source?
sauceNao comes up empty.
akuma no riddle
reddit
>>Roll up to a big fricking factory that seems to be producing factories
actually funny, too bad rest of the post it goes downhill from this
excellent
qrd on your points
Mostly good, I don't adhere to "Clean Code" because I'm lazy but I can see the benefits. The part about small functions is pure shit though and early abstractions are never good.
Which is basically what Clean Code is about. Read the book before you recommend it! His code is shit.
maybe you should read it, it's not all about small functions. it's actually kind of minor part of it
I have read it. Small functions is chapter 3, and the other chapters are equally useless
naming things properly is useless?
>he thinks naming things solves everything
No there are parts of clean code that are good but there's some core philosophies that really fricking suck ass
You need a fat homosexual to tell you to not name functions foo()?
I know this is bait, but the #1 thing that's bad about clean code is its underlying mentality. Clean code is all about the programmer, not the program. When I code, all I care about is the program, not my experience making it. When I use software, I don't give a frick about the experience of those behind it. If it works, I'll use it. You can argue that clean code helps to make better software, but that's provably false for everything is shit these days. Ultimately it's a skill issue.
Write code that's good for the hardware and experience of the user only.
t. has never maintained anything of significant size
Goddamn, what a shit take.
Clean code sucks but damn you suck harder.
I don't think you're wrong that clean codes subtext is more important than its actual content but you're wrong about its subtext. Clean code is about how programmers can use only code to communicate with one another. The main objective being fungibility, aka replace-ability but the bright side is less contact with my peers, while I still have a job.
The book "Clean Code" gives bad to mediocre advice
Writing your code to be easy to understand and debug and modify is an incredibly important skill
I'm not a Caseyologist but I get the impression that he only understands his own immediate context and just assumes the whole world works like that, not worth your attention
Never read it, I don't need it. Clean code is functional code. Comments solve whatever else isn't already covered by the clarity of FP (like why there's a random delayer in the middle of the program)
the basic idea is good, but the clean code fanatics often go too far and ruin the program with their clean code autism
What is funny about Clean Code is that everyone is praising it, but no one has read it, nor follow it. And when you ask what you can learn from it people generally say:
>Good names
>Short functions
Without going into specifics of what either of these mean. And honestly, good names? Do you really need a fat homosexual to tell you not to name a function foo, or a variable x? Isn't this something that everyone figures out by themselves?
I think the best cure against the Clean Code madness is to actually read Clean Code, and specifically Martins own code written in his own style. It is dogshit.
Good post.
Threadly reminder that some of Uncle Bob's own examples of refactoring on real world code introduce serious bugs and almost nobody spots them because of the way everything gets obfuscated under 10 layers of private functions operating almost exclusively via side effects.
plenty of cnile ""performance"" code out there with a's and b's as variable names
There is nothing wrong with a and b if it makes sense because what they are reffering to is abstract to begin with. Let’s take a simple example:
Int highestAbs(int a, int b)
{
Return abs(a) > abs(b) ? abs(a) : abs(b);
}
This code doesn’t need to know what a and b are, in fact it would be detrimental for it to know. Nor does it help anyone to rename a and b.
The problem is when a and b refer to something concrete || gets used later far away from where they were declared and context isn’t available.
And nowadays enteprise Black folk just take a random noun and slap it on a variable, without regards for the meaning of either, because it's "descriptive" therefore good.
DI can make sense for projects with tons of generic components seeing a lot of reuse (ex. you have one messageProcessor<T> with a dozen concrete instances), but I agree that it's overused to the point of being a meme.
One of the homosexual TLs at work has spent weeks on DI wankery for a tool that's supposed to automate a simple update on ten database rows a day, tops.
Doesn't help that his team is full of juniors and pajeets, so they all think he's hot shit.
>And nowadays enteprise Black folk just take a random noun and slap it on a variable, without regards for the meaning of either, because it's "descriptive" therefore good.
strawman
>s-strawman!
Literally something I see at work every day.
var path, it's the filename without extension.
var email, it's the username.
var dateString, it's not a date nor a string.
nta but tbtbh anon you need to go and work for a different company
that sounds fricking horrible
why do you work for a junior farm?
I read it a while ago but the only thing I remember is that 'clean code' should consist of 1-4 line functions with descriptive names (at least I think it's from the clean code book). imo this makes it hard to understand what's going on but at the same time you can't have 10 minimum wage 'jeets working on the same file at the same time otherwise.
>And honestly, good names? Do you really need a fat homosexual to tell you not to name a function foo, or a variable x? Isn't this something that everyone figures out by themselves?
extreme shorthanding and memorizing what each thing does is common in C and C++, where people also still stick to the "no more than 80 characters per line" rule religiously , but that what's a good C practice won't be a good Java practice
Integer.parseInt(s) is more descriptive and easier to just read and correctly assume what it does than itoa(s)
also, "x" is a perfectly fine name in certain cases, just don't make its scope too large
>extreme shorthanding and memorizing what each thing does is common in C and C++, where people also still stick to the "no more than 80 characters per line" rule religiously
What the frick are you talking about? Yes, some c and c++ functions from the standard library are opaque because they were written decades ago and we had other limitations on HW. But that isn’t something common with C or C++ devs today.
it still used to be a principle that was being taught last time I had to touch C
and "being written decades ago" doesn't change the fact that it's still unchanged today. or have itoa() and atoi() been deprecated for something more readable?
in any case, even if C people learned to write longer lines, there's probably a lot of other things that would be a good practice in C but a bad practice in Java, and vice versa
Then you had shit teachers, grandpa. What would be the point in rewriting atoi just to give it a new name? Better to ensure that new code is more descriptive
I think you're a terrible reporter.
Naming things like that is a learned behavior. All the people who need to be told not to name things like "itoa" are all annoying nocoder IQfy cniles who got memed into not learning something useful like Python.
>Do you really need a fat homosexual to tell you not to name a function foo, or a variable x
have you seen the shit C Black folk churn out
I don't need a god damn book to know clean code, I have my own guidelines
>descriptive names
Unless it's a throwaway variable everything has a descriptive name, I make use singular and plural forms, same for functions/structs/classes
>short functions
If a function is not fitting in one screen I'm doing too much in it so I split it. Usually when a function does too much then it can't have a descriptive name so rule 1 actually guides me in this one, e.g. if a split function can't have a descriptive name then it shouldn't have been split so I join it again
>no comments
My code should be effortless to read like prose. And then no comments are needed, everything describes itself. Applying the above 2 rules leads to a huge reduction of comments and self documenting code
>don't sweat it
Working code is more important than clean code. I won't follow any rule religiously if it's going to shit on my project.
Hard disagree on both clean code and short functions. Bob C. Bobson has basically co-opted the term so if you say ”I do clean code”, even if you don’t mean it people will assume that your code has Robbies seal of approval. In the absolute worst case you are actually good and therefore unintentionally lead poor juniors down the path of ”Clean Code”-code because they want to be like you. So they buy his book.
And regarding function length, they should be as long as they need to be. If you have a long ass function that needs to perform many steps to do one thing you don’t actually have a function that does ”too many things”, just a function that does one big thing. Splitting this function into smaller functions doesn’t in any way reduce the amount of steps you need to do, or reduce the smoking of code you need to keep in your head. It only makes the function more annoying to read and reason about. We can all agree that functions shouldn’t be longer than necessary, but assigning arbitrary metrics to determine this only shoots yourself in the foot.
Read my number 2 rule carefully. Naming guides what I should do. If by splitting a big ass function with descriptive name in 4 small functions with non descriptive names that now have to have comments to remember what they do then I don't split. But usually without even consciously trying I end up with small functions with descriptive names that do something concrete and atomic.
You can split a big function into smaller functions that do something concrete, with concise names, and still end up with functions that get called only once and fulfill no purpose on their own. I get what you are doing because I do something similar. When I write functions I start with just a heading and input/output. And may write several of these to understand how I think I want to put everything together. Then I actually code. And sometimes code needs to be repeated and gets put in its own function (if it makes sense).
I agree that simplicity is beautiful. I also always look for the root cause of bugs, never "patch" bugs somewhere half-way in the chain of events unless you're making some temporary hotfix. Consistent code is also good.
I mean, I agree with a lot of it, but certainly not a fan of all of it. For example, my experience with dependency injection is mostly .NET Core code, I think dependency injection is fricking stupid honestly and it complicates the program instead of simplifying it.
same opinion as on all of these fads:nice guidelines, but nothing actually new; and guidelines only, that you will need to break daily
I'm like this homosexual. I talk a lot about how software should be written and I keep pointing out mistakes when oither people write something. I regurgitate talking points I find on Hackernews and other places and people think I'm such a fricking expert at everything.
I can write some spaghetti piece of shit and I actually I know frick all but I am charging the client a good amount and only a fraction of it actually goes to the developer.
If you're in the software business and you're the one writing the code, you're a fricking moron.
Necessary evil for sufficiently large projects with multiple chefs in the kitchen. The alternative - letting everyone freestyle their shit and then expecting everyone to step in and debug what amounts to schizo bullshit in an emergency - is moronic.
You need to establish house rules.
You need to test your code.
Your code should have minimal side effects and be maximally deterministic.
>Necessary evil for sufficiently large projects
Hell no it isn't. What's easier to debug;
A subroutine with excessive amounts of masturbatory abstraction where each of those are split into individual files or just HAVING THE FRICKING CODE THERE.
Imagine writing something like virtual baseAbstractFactoryFactoryFactoryComponentImpl and not crying yourself to sleep every night
The answer depends on number of side effects. A single massive function with branching conditional, nested functions and a shitload of shared state is going to be a pain in the ass to deal with in a sufficiently complex codebase where things happen asynchronously. And even for synchronous code, writing massive conflated shitpieces results in shit that's going to be harder to refactor later.
Oh yeah Uncle Bob's examples are dogshit but the concepts he's talking about are correct.
Minimize side effects, not remove them entirely. Smalltalk style message passing is the right way to OO if you must OO.
>A single massive function with branching conditional, nested functions and a shitload of shared state is going to be a pain in the ass to deal
I mean no shit I'm not saying you start writing your code like a moron
Except that's usually exactly what happens when people say frick clean code and you have several dozen different people working on the same project. Each one introduces their special global variables for their special functions that compose or inherit from other people's special functions and global variables.
Nobody is testing shit because its become too massive of a task to think of all the different execution paths that the program could take.
It's tolerable at first, silently spirals out of control, and then suddenly you're stuck working 80 hour work weeks hunting down heisenbugs and debugging race conditions silently introduced by code merged in from some guy that left the team half a year ago.
What you're proposing is that there are zero coding practices at all. It isn't really about clean code at this point.
Slippery slope fallacy isn't a fallacy when it comes to this stuff.
You can still enforce practices without having to suck the tit of excessive polymorphism, abstraction, dry etc. No one is advocating for people to start writing like webjeets from the 2000s.
>No one is advocating for people to start writing like webjeets from the 2000s.
Nobody advocates for living in a crackhouse either, but it still happens to people because of the choices they make.
Are you saying that modern software companies are any different from people huffing abstraction and polymorphism crack smoke? Look at the absolutely moronic state of Microsoft.
The reality is that we went down the "clean code" slope and it has seriously harmed software as a result. This isn't even a "oh but z might happen because a", it did happen, it's real. Maybe it's time to look at it from a different perspective.
Maybe it sucks.
>we went down the "clean code" slope
When? In most places I've only seen people fighting it and still using mutable global state alongside their weekly alpha and omega functions that they need the whole team to help them debug every weekend when prod is shitting itself.
Places that are actually doing CC are far and few between, or you have people claiming they're doing CC when they're really doing pic related and just abstracting things into batshit insane mode instead of doing the core stuff such as reducing mutability and shared state, composition over inheritance, doing one thing and doing it well, etc.
jumping between subroutines and files while debugging is a complete non-issue when you use a good IDE
No, it's stupid having everything out of context even in an IDE. I have to question whether or not you've even tried the alternative to see for yourself.
>having everything out of context
the functions define the context
having more small functions makes for smaller, more precise context in each
surely you're not so mentally challenged as to not being able to comprehend anything but flat global state?
I'm not in particular arguing against functions though, like I said earlier. You're taking in this in the context that everyone should just write moronic code instead, which is not what Casey or anyone else is arguing for. It's just a blatant misrepresentation.
>You're taking in this in the context that everyone should just write moronic code instead, which is not what Casey or anyone else is arguing for.
Have you seen Casey’s code?
He isn’t a gamedev.
>Have you seen Casey’s code?
I'm not shilling this homosexual. But that code makes sense to him. If you don't like it, you write it your way, make it public and lets see if we can read it all and conclude: yes this is "clean" code.
You fricking dumbass.
Lets see anon's code.
He killed BILLIONS of sóydevs
Maybe he did offend a lot of programmers concerned with everything except for programming, but his advice is meaningless unless you write programs with systems programming languages. The fact is that the vast majority of popular programming languages have so much unnecessary runtime overhead, that what you could gain by writing simple code is completely offset by shit efficiency of the managed language. You can extract single-digit percentage performance improvement by writing simple linear code instead of OOP monstrosities, but it's just not worth it most of the time.
Look at Python - it's at the level of excruciatingly slow where you can exclusively `raise` exceptions instead of `return`ing values for the convenience of try-except pattern matching on different cases, and it's just as slow as a simple if-else block.
I would say his advice is stupid because he isn't operating in the ballpark of performance he is complaining about. b***hing about virtual and cache/prediction optimization is meaningless when what he really b***hes about is precisely someone writing in Java, or worse Javascript. Frick in the first place a lot of 2000-2010 were still firmly written in the OOP model and he will bring a program from basically that time and b***h how much the performance degraded compared to some contemporary alternative.
java isn't inherently slow, but i've used some "enterprise" java software (some apache data software) and it is slow and bloated
>java isn't inherently slow,
It's about as inherently slow as virtual functions or OOP code in general is, unless you're fighting the language itself to get something optimized but I am kind of green in the area of performant Java code and how hard can you make something utilizing SIMD or work on data locality. Which is kinda what Casey is scrutinizing, where his silver bullet for non performant software is just the bad OOP, never mind when fricking windows has always been based on OOP and virtual tables in win API.
>but i've used some "enterprise" java software (some apache data software) and it is slow and bloated
Yeah you can make just about anything unbearably slow by doing stupid things, but in general you can avoid doing those stupid things in any paradigm.
in the first few minutes he literally admits the biggest problem with clean code. It's subjective and means absolutely nothing.
why is this homosexual using C++? Pretty sure the boomer galaxy pic clean code book is java jeet shit.
comparing OpenJDK's compiler to any C++ compiler is like apples and oranges.
>Smaller
No, because context in one function is now suddenly depending on context somewhere else to make sense
>More precise
Also no for a similar reason
We can both agree that functions should have a purpose, yeah? Functions should do one thing, yeah? Clean code creates functions that do nothing, and to get this ”one thing” you have to sum up many functions that call each other. And if you follow Bobby C Dobby’s advice they also operate exclusively through side effects
>No, because context in one function is now suddenly depending on context somewhere else to make sense
if your code ends up with dependencies like that, it's solely your fault for writing shit code
i'm actually having a very hard time imagining how do you even frick up something as simple as an "extract method" refactoring. i've seen it happen, but in every case it's always been the author being absolute garbage at writing code anyway
>Clean code creates functions that do nothing
no, again, it's you being bad at picking out things to put in a separate function
even if it's some private method that is being used only once, it can still create a narrower context/scope for the operation that specific method does, so the method that calls it can have a smaller, cleaner context. whether that actually happens or not, entirely depends on your abilities to write code
>if your code ends up with dependencies like that, it's solely your fault for writing clean code
fify
House rules != Clean Code
>Your code should have minimal side effects
So, the opposite of Uncle Bob's refactoring examples.
>Your code should have minimal side effects
that by necessity means that your code cannot be object oriented because by design OO works exclusively through side effects.
>by design OO works exclusively through side effects
No it doesn't, wtf are you smoking?
You can easily write OO code that works just using return values.
>inb4 constructors are side effects
I don’t believe it myself, but I think it sounds funny: Constructors are side effects
Why would you even consider OOP in the first place if your program has little to no mutable state? Isn't one of the OOP things people do is "protect" or "encapsulate" state? Sure, you can do it, but what you are doing is no longer OOP, it's pure functional programming with weird closure definitions.
"little" and "no" mutable state can make a world of difference
NTA and also dislike OOP but I wouldn’t equate changing state with side effects. If it is explicitly clear from your functions that states will change then you can’t really call it a side effect. It is just an effect.
As an example, take shared pointers in c++. Adding a reference increases the ref counter by 1. This is a change of state. It is also a state change that you as user have no control over. But is it a side effect?
Or say that you have some sort of dynamic list or whatevs, and that has a counter that keeps track of the number of elements. You insert an element. Is the counter update a side effect?
Changing state is literally the definition of a side effect.
This isn't a vauge concept.
You can have intentional side-effects, but they're still side-effects. It's not necessarily a value judgement.
if you primarily think of subroutines as functions, a.k.a things that produce output (return values) based on their input (arguments) then anything you can observe as a result of having called them are side effects, or indirect output.
You can infact build archirecture around pure functions and build big complex systems around that idea, and only allow for state changes/side-effects at the edge of your system. Not only is this possible but works remarkably well for way more use cases than people would assume.
I see. Then Clean Code makes even less sense, as well as the general hostility against side effects. They are just a tool like anything else
Sorry bro, hostility against side effects makes perfect sense for anyone who has found themselves debugging legacy code.
Side effects seem fine when you're building your mental model alongside the creation of a greenfield project with a puny LOC total. They are pure hell when the codebase is 100K+ LOC and 50+ devs have snowballed more state and bugs back and forth than a San Franciscan polycule.
I’ve debugged plenty of legacy code professionally. I know the dangers. But I also see the benefits of modifying state. As everything else you need to be smart about it.
This man knows. Inheritance + side effects + event handlers is a nightmare to maintain. I got so fed up I moved fully over to immutable state with pure functions, and I've not had any problems since then. Everyone at my new job loves my code.
what if internal changes of state do not affect any results produced by the object?
then you're literally just wasting CPU cycles.
literally why bother
NTA but why would anyone do that? It would be better to just have everything in a function instead in that case.
Then it's still a side effect because a poor junior can come along one day amd be tasked with adding some business logic relying on that state without zero awareness aware of your hidden frickaroo logic spinning up race conditions under the hood. Great idea for job security, though.
I forgot a very important "else" in that last line.
anything else, besides a functions direct output (return value), that you can observe as result of having called it are side effects / indirect output.
I use out parameters in C++ all the time. Not because I think it is good, but because the alternative of using tupels and pairs is so much worse and less performant. Sure, the performance hit is really minimal, but I mean, why? I’d rather work directly on the objects I have instead of making a fricking copy and tossing the original
Well, out-parameters are at least explicit.
at least the caller has complete control over where those side effects get placed.
How ergonomic it is to use direct output instead is dependend on the language I think.
If you can't easily define on the fly data-shapes to describe exactly what you wanna return then thats on the language.
this. large code bases with heavy side-effect driven behavior can often turn into rube-goldberg like clusterfricks with totally inscrutible and confusing design.
It is extremely easy in C++ actually, just annoying. I can on the fly make a tuple of say an int, a string and a struct F through std::tuple<int,std::string,F> data = std::make_tuple(i,s,f);
And to access say the first element
int j = std::get<0>(data);
Easy, annoying, boring
yeah thats exactly my point
having to do this:
>std::tuple<int,std::string,F> data = std::make_tuple(i,s,f);
when you wanna return an int a string and some third thing is way too much of a hassle
no wonder you woundn't want to do that.
especially if you have to write out that generic clusterfrick of a type definition multiple times,
which I assume you have to.
std::get<0>(data)
also is way to fricking moronic and cryptic for what it accomplishes.
I'm in a love/hate relationship with C++. I love the language, but I don't love how it treats me. But everytime I try to leave it it always comes up and starts to treat me right, only to later hit me. Sometimes I wear sunglasses so that others can't see my black eyes.
try using cppfront then, all the good of semantics of C++ without the random gotchas of an older syntax.
Will check it out. Thanks anon!
According to OO theory, individual objects interact with each other through messages, which in languages like java and C++ generally translates to method calls.
Objects are supposed to be opaque and not have access to data of other objects.
Thing A sends a message to Thing B and as a result, Thing B might send various other messages around and more importantly modify its internal state that no one else has access to.
I don't know what you would call that but that seems to me like a system that exclusively works through side effects.
In true OO, objects shouldn't even be understood as data-types, since you're no supposed to have access to any data.
They're unknowable things that you can only interact with through their specific interface, a.k.a the messages that they accept.
I think this goes without saying but this is obviously a horrible, disasterous, mind numbingly awufl idea.
>Thing A sends a message to Thing B and as a result, Thing B might send various other messages around and more importantly modify its internal state that no one else has access to.
now dress that into a concrete example rather than meaningless abstract "A, B, C" entities
pretty sure you either won't be able to make an example where your scenario fits and makes sense, or your example will have its design flaws very visible and just asking for getting refactored
I am not proposing to build systems like that.
That is obviously moronic.
It's just that this idea is the core of OO.
Which is why OO is also moronic.
>I am not proposing to build systems like that.
>That is obviously moronic.
i.e. strawman
you make moronic designs, then blame OO for being moronic
>It's just that this idea is the core of OO.
except it's not
Sir! Why are you lying sir? Why do you talk so much incorrect things you b***h bastard?
OO means "object oriented", not "mutable state oriented".
A shitload of business logic can (thankfully) be boiled down to the following:
>parse some data with object A to create object B
>feed object B to object C, which does some processing and spits out the result as object D
>serialize object D to database/filesystem/whatever by using object E
Zero mutable state required or even desired, every object except B and D can be a static class even if management Black folk prefer singletons created by bloated IoC systems for some ungodly reason.
>in true OO, objects shouldn't even be understood as data-types
Says who, some functionalgay?
Learn what a Data Transfer Object is.
Frick, forgot to tag
also yes, constructors definitely are side-effects, and encourage programming styles that rely on side-effects.
They're absolutely awful. Them causing heap allocations is the less interesting part, but the way they are implemented in popular languages is a plauge.
>HMM #811 Fixing Lighting
>HMM #812 Fixing Lighting
>HMM #813 Fixing Lighting
>HMM #814 Fixing Lighting
>HMM #815 Fixing Lighting
>HMM #816 Fixing Lighting
>HMM #817 Fixing Lighting
>HMM #818 Fixing Lighting
>HMM #819 Fixing Lighting
>HMM #820 Fixing Lighting
>HMM #821 Fixing Lighting
>HMM #822 Fixing Lighting
>HMM #823 JBlowing JBlow
>HMM #824 Fixing Lighting
>HMM #825 Fixing Lighting
>HMM #826 Fixing Lighting
>HMM #827 Fixing Lighting
>HMM #828 Fixing Lighting
>HMM #829 Fixing Lighting
>HMM #830 Fixing Lighting
>10 years
>no game
how does he do it? roller coaster tycoon didn't take this long.
>clean code
gay
>short code
high IQ
>no code
Abstraction doesn't exist in software. It simply materializes components and systems out of innate memory, much like life materializes out of innate matter, in more and more complex ways. If you have a factory that makes factories that's because there is an actual need to do this, but your mind is simply not powerful enough to understand these virtual systems beyond "array and ints" gruggery
If you want clean code you should hire a code maid, not my problem.
clean code is the code that I write and bad code is the code that you write
clean code is the code I write now and bad code is the code I wrote 2 months ago
Muratori is based.
Clean code cultists are moronic.
You should only make your code clean when there is a clear advantage towards organization and maintainability.
You shouldn't worship it like some religious universal truth or some shit.
Just be high IQ and your code will look nice, if you are a dumb room temperature IQ your code will be garbage regardless of the "principles" you follow.
what is with everyone idolizing opinions of game devs out of all people. they never wrote anything that needs to keep the world running.
You make a good point, do you have some unironic recommendations.
irrelevant boomer meme. how were they wrong about literally everything?
How do you cope with programming in a dogshit language like Python? Every stupid library function is throwing 17 different exceptions, everything is polluted with try except except finally raise ShitError from PissError. Look at the top used libraries and frameworks. They all reuse the same exceptions for both trivial local control flow, and global "error handling". Why are these people allowed to write software?
No one is advocating unnecessarily "dirty code". The problem is that some moronic hack established a set of dumb standards promising simple answers to complex problems, and it was accepted as gospel by clueless juniors (I used to be among them).
And now I'm guessing you're either a product manager or a senior who's never made it to lead.
game devs were a mistake
>What's your opinion on "Clean Code"?
Never heard of him
Don’t look him up, he is a huge blob of bad ideas and fat.
"The Elements of Programming Style"
And
"K&R C Programming Language"
Is all you'll ever need, anything else is troony/Corporate shit.
If with those your code is still shit go become a webdev or something.
>"K&R C Programming Language"
riddled with typos and code samples that don't work
What's readable for a human can be detrimental for a machine.
It's obvious, really
i am not the machine's b***h
the machine is my b***h
pOOPers BTFO yet again
blue board, no racism please
i hate how arbitrary it is and i hate feeling like shit about my code without knowing why because it could be messy by some standard
Casey isn't willing to touch on the real reason software is slower now. Clean code is at most a symptom, it is not the problem.
because system programming is 100x easier than business programming.
it's easier to optimize a 10k C code by hand. it's fricking impossible to do the same with a massive backed that orchestrates thousands of objects.
it's even impossible to reason about massive backend behavior and keep in a head all its routines and corner cases like you would with your average C driver.
that's why safe and robust code is preferred over fragile performant code.
>hmmph, tell me what to do to make my life easier, will you?
>i'm going to make my code deliberately bad to spite you!
I'm not going to @ all of you but this is peak IQfy chuuni/ contrarianism. You won't even follow through with it, of course you'll try to write good code.
Not as useful as working code delivered on time.
After reading a bunch of articles with negative hackernews reception, and watching a few contrarian israelitetube videos on this topic, i sat down and started programming "like a moron". The experience was eye opening. It turns out that simple and stupid procedural programming is not only significantly more productive, but the end result is more correct.
Here is how you should program:
1. Write a sizable chunk that does what it should do.
2. Replace repeated code blocks with function calls.
3. Repeat until the program is finished.
If you write in a fancy language with cool features like RAII and exceptions, don't bother. Just use if-else statements. I also find that a single return statement at the end of the function leads to better design.
i'm going back to structs and global arrays
i'm so sick of all this dependency neo-drama. it used to be that you could make an assessment on whether to adopt a package or stack dependency based solely on its technical merits / trade-offs. but since pozzed, golemized millennials took over software, every possible software dependency you might need for your project now carries with it a bunch of potential troony marxist loxist political drama. i've used modern langs / platforms to build my software to peak abstraction heights. and while it was really nice in many ways, i don't know if it's worth all the drama of sucking in layers and layers and packages and packages of dependencies that you can only get support for via their 'communities' if you submit to the #currentthing ~~*troony*~~ dick. imagine considering a dependency on a package then looking for their support community and finding it plastered with pedo rainbow colors.
so i'm going back to structs and arrays. every language supports these, all the way back to C. I will write every last goddamn line of code in C if I have to in order to assert my self-ownership in this dying techno gay hellscape. And I can use these technique in any language and therefore any corporation that I might need to merc for for shekels.
you can do everything you need with structs and global arrays. and goddamn 95% of the time at least, it will be soooo much simpler not to mention performant. if we really need a kernel-style abstraction layer, C has static declarators that hide visibility among translation units (hopefully I got the verbiage right, correct me if I'm wrong).
We as programmers have everything we need, and we've had it for decades. And now we realize the true cost of our unnecessary dependencies and their israelited censorship industrial complex by way of 'codes of coducts' and ~~*sensitivity standards*~~.
please never publish your insecure hackable binaries
not like you were ever going to publish anything you make but still
Just compile it with shadow stack enabled. It prevents 99.9999999% of accidental security problems, if the program is moronic.
the troon doesn't know what a shadow stack is
>homosexual poster is back
have a nice day.
"Clean Code" is only clean if it's make things more readable.
If it's not making things more readable, and instead it becomes a Pan's labyrinth then it's akin to liquid diarrhea being sprayed in random files instead of where it frickign belongs.
And clean code shold never be a deciding factor in critical sections of code that are executed many times a second.
And I mean in the case that, pursuing "clean code" makes it impossible to optimize.
>And I mean in the case that, pursuing "clean code" makes it impossible to optimize.
ironically, clean code makes it easier to optimize code because it's easier to tell what the code is doing in the first place
"optimized" code is often unreadable and almost always unmodifiable
>And clean code shold never be a deciding factor in critical sections of code that are executed many times a second.
you make it sound like critical sections are 90% of code in a codebase
you can still have general clean code with fast critical sections
You don't do optimizations because they look pretty, you do because it's necessary.
Optimizing something that has been abstracted too much that you no longer have a grasp of the data structure, is as enjoyable as taking a dive into a meat grinder.
If you know that something will need optimization, perhaps it's better to avoid abstracting that code too much.
And no, not I'm not making it sound like it's 90%, I did specify I'm talking about code executed many times a second. Most things don't matter, but rendering, game loops, and other stuff that fall into this condition is always worth optimizing.
>You don't do optimizations because they look pretty, you do because it's necessary.
ideally, yes; in practice, people who are obsessed with optimizations and performance will push to "optimize" everything, preemptively or otherwise, and always sacrifice maintainability
>Optimizing something that has been abstracted too much that you no longer have a grasp of the data structure, is as enjoyable as taking a dive into a meat grinder.
you equate clean code to "abstracted too much"
- you can do clean code without going overboard with abstractions
- you can have overly abstracted code that's not clean in any case
>Most things don't matter, but rendering, game loops, and other stuff that fall into this condition is always worth optimizing.
who even implies that kind of code is the target for clean code in the first place?
clean code is for high-level business logic and complex workflows inside enterprise software
Why are you arguing if we are in complete agreement?
"clean code" != clean code
I love clean code, with the distinction that my code is clean and other code is unclean.
The namesake book is terrible.
My opinion is I hate opening up a program only to find a diarrhea swirl of endless files with layers and layers of dependency between each other so trying to understand flow control is impossible.
When you write code this way, I honestly don't see what's different about it from standard spaghetti. It's just as much a mess, except now instead of just the creator being the only one who knows what does what, NOW every fricking modulated part is only understood by ITS creator, so you just have this slodge pile of chunks that are designed to interact with each other, yet have no coherence or consistency with each other. "Clean Code" isn't clean code, it's crap enterprise code meant to work on a conveyer. And there is nothing wrong with generic variable identifiers. I don't need everything to be a fricking detailed description. X is an iterator, Y is some temporary value. It has no importance so it gets a generic name. Put 2 and 2 together. Tired of reading code that is more English than programming with the moronic cameCase identifiers that are longer than the rest of the statement.
why are people filtered by enterprise code always so obsessed with scat analogies?
Wow you Black folk are fricking moronic
How can code be clean when keyboards are officially the germiest item in a household?
meme that doesn't work
Comment the purpose of ALL your methods, or you are a disgusting subhuman
Ensure all your applications have 1 clear entry point
Do NOT have objects calling other objects ad infinitum, a method should not have nested other objects inside of it making new calls
Continued: If you have a method with other objects inside of it calling other methods, that isn't a method - that is a framework
Show me what "dirty code" is.
just look at your code
GOT HIM!
What's up with the muratori posting lately? I mean JBlow is a quintessential IQfyceleb but muratori?
I won’t complain because Muratori atleast knows what he is talking about
>a failed gamedev with one unfinished project
>knows what he is talking about
this is peak dunning kruger.
just because he knows some low level algorithms doesn't mean he is a good software designer.
design isn't about implementation, it's about how you stick different implementations together.
Muratori knows what he is talking about from a programming perspective. Developing products is not the same as coding.
I don't read books about programming. I read codebases and occasionally whitepapers.
Anyone know where I can get a free copy of the HH source code? Not looking to pay $15 for access to a repo.
watch the videos and code along