:big sigh: The industry recommends writing clean code... and what do we see pervasively in real projects at work? : )

I think you'd have to be lucky to join a company that doesn't write messy code... not just in one project, but in all. Legacy. I hate legacy. Arrghhh.

lol.

There are two types of people. The one who write clean code and the one that gets shit done. - tsoding.

Not only that but the "Clean Code" principles are mostly bullshit.
They don’t result in good code.

Experienced devs all agree on that.

@whimsical writing supposedly clean code is not contrary to get shit done.

That‘s just something that sloppy coders tell to themselves to have an excuse to proceed to write shit code.

idk how much of it is that code is spaghetti/sucks vs the person reading it just doesn't have enough expertise to know that's the best way to have done it

over time "cleaner" code becomes more efficient to write things in so the whole thing is a false dichotomy anyway... just don't get fixated in a stupid tunnel. if there isn't much difference between one way or the other you're over-optimizing unnecessarily/nitpicking and going off course lol

Hmm... I think the the source code of the 'Descent' has been made public for the reason of showing people what a released game's code quality looks like.

'Mike: The main reason is we figured a lot of people aspiring to work in the

game industry would like to see production "quality" code. There are two

reasons for this. One, you can learn a lot by looking at working code.

Two, people will see that you can write a decent game without writing

beautiful code.'.

https://github.com/videogamepreserv... .

/* An outstanding game, btw... I remember this being one of the first PlayStation games I played on the platform. 1st game I remember that had you control something in a fully 3D space. */

@jestdotty spaghetti isn’t the single thing that makes code bad. And there is not a single thing that makes code clean or good.
There are a lot of different categories and factors to good and bad code.
And nobody just decides to write good or bad code. It‘s always a mix.
Everybody is aware of that.
It’s not a false dichotomy.

@Lensflare idk what you're aware of. that just sounded like inanity to me. it's also really funny

@jestdotty it‘s like your mind is constantly in another dimension or alternate reality where all of the devrant posts and comments are slightly different.
Your answer appears to be addressing something that another version of me has said in your reality.
In my reality, it barely makes any sense.

For 9 years I worked in a company that promotes clean code in all the projects. I've learned it, even tdd too. Frankly, it is not shit. Following those few principles you make your architecture flexible and resilient and very much maintainable at the same time.

Clean code is rubbish for mvp/poc, I give you that [tdd - not necessarily]. But for long-term codebases it is the only way to have a peace of mind while working on it at any given time, on any given task.

Now I work with guys who are very eager to deliver asap, and clean code or clean architecture is not in the dictionary. And I can tell that maintaining all that crap is hell of a pita. Yes, clients are mostly startups, but in all the cases they ask for an mvp and lts maintenance afterwards. We are making major refactorings every ~9 months. It's like an mvp gets us pregnant with a slightly cleaner mvp and 9 mos later we're delivering it and a month later we start getting the feeling that yet another one is growing inside us.

I've delivered a couple of features and I'm confident noone will need to touch them for at least a year, because they are solid. In both meanings. And I'm already about to port the same things to other projects. I might as well publish them as standalone OSS frameworks..

Tbh clean code is "clean code" by definition. You can't expect to follow a bunch of best practices blindly and magically get clean code and then complain that "clean code is bullshit". That's an oxymoron. Clean code isnt some symbolic depiction of DRY and SOLID and other principles. Clean code is what you get when you both: know what you're doing and keep maintaining it during development. In my years of experience I find that being willing to refactor code as you go is the path to clean code. Write simple first, verify function, then refactor and organize and finally maintain (which also means, make sure the design you started out with is also kept or updated during PRs). That also goes for other peoples code. Before you implement something in a new codebase at least skim over it so you underatand where the author intended things to go. You will often find design gems in code that looks messy at first

@Hazarth yes and no.
Clean Code is also this popular book and a lot of people understand clean code to be an application of those specific rules from that book.
And unfortunately this book gives quite a lot of bad advice.

@jestdotty The times it is spaghetti and sucky code it's written by either non-caring seniors or very junior devs.

From my experience, a requirement for code going to production was for it to be clean because of reasons such as time and money.

I do thank myself for making code flexible because in the particular framework I wrote it allowed easy portability to switch up frameworks when desired instead of the nightmare of rewriting everything.

What is clean code? Well, code that doesn't smell (haha). Code that adheres to SOLID and such, the use of interfaces, of common patterns.

nice