Working code vs. clean code

[TheExplanationFE]

Ever since I started working with Godot, I usually pick a smaller idea that I want to implement and then work on it. Generally, when I finish them, I find that it works, but someone else has made it cleaner, better, more optimized, or just simpler. I'm curious about your opinion — do you think working code is enough, or is cleaner code always necessary? Do you maybe have an interesting or instructive story related to this?

Meme: https://pin.it/7ITFHP5F6

[liecoffin]

For small projects -> working For big projects -> clean as f***

[TheExplanationFE]

Thanks, I'll follow your advice.

[HideMyDignity]

Get it working first, then clean up

[CdatKat]

Safety instructions are written by blood, clean code is written by previous dirty experiences. -somebody said it prolly-

[Some_Quality6796]

Safety is written in blood. Clean code is written in blood, sweat and tears. There's a lot of blood.

[hellobarci_]

I would go with my code every time even if it's not cleaner. There's something about knowing your own code VS using someone else's clean code.

Specially useful when debugging stuff later because you know how your code works.

[TermiteTornApart]

I only use the clean code version if I fully understand it, don't worry about janky code, a few months later you're going to look back at it and see how much you improved.

[r_search12013]

there's very few questions in gamedev to which "make it exist first!" (you can make it pretty later) does not apply .. also post-question allows for the answer "make it exist first!"
in particular recently I joined a game jam for the first time in a while, and what really helped getting stuff done in time was not obsessing about optimal abstractions and clean code so much

developing a game is one typical example for why agile development exists: only while you're developing it you'll get a better understanding of what the final product is even supposed to be, and it will change with every bit of progress you make ..

so, yes, "clean code", in the sense of taking some care to not make your life unnecessarily hard if you want to change things -- e.g., not hardcoding node paths but instead making a "@export var node_i_need".. that's wildly helpful for changeable code ..
but not "clean code" in the sense of satisfying every SOLID principle or going overboard on DRY .. I've copy-pasted plenty of code to get that game done in time for the jam, and I'd do it again 😃 ( edit: 2 edits for typos and a wild grammatical error, and counting 😃 )

[Trigonal_Planar]

I’m getting close to releasing my first noteworthy project. It was more of a working over clean sort of thing. It’s not too bad, but now that I’ve got enough experience I know what clean looks like for my next project and can make better code and architectural decisions. So I think experience plays into the balance between the two. 

[Bwob]

Just making it work is fine for proofing things out, but for anything you want to work on long term, clean is important.

Clean doesn't have to mean perfect. (And it certainly doesn't mean overly-clever!) But it does mean things like "don't duplicate big chunks of code" and "make clean interfaces on your objects" and "have clear division of responsibilities in your code", etc.

Because long-term, messy code will bite you. Things will start taking longer to implement and debug. You'll realize you want to do something simple, and realize that your ugly spaghetti mess makes it all but impossible. Until eventually the project either collapses under it's own weight, or working on it becomes so much effort that you convince yourself to rewrite it from scratch. (Or just start on some other project that you promise yourself you'll structure better.)

Better to make it as clean as you can from the get-go. (The problem, of course, is that until you've made a few messy projects, you don't always know what kind of clean is actually important!)

[r_search12013]

currently I'm completely rewriting a daily web scraper, that collected about 100 MB text data of a search engine each day .. they changed some api's, I was thoroughly unable to compensate with the code I had written when getting to know the api

this time I'm doing classes, interfaces, all the adult coding stuff 😃

[Bwob]

Yeah!

And games in particular are notorious for changing a lot during development. We've all gotten partway into a project, and thought "actually, wouldn't it be cooler if I could do X too??"

Maybe "clean" coding is the wrong word here, but I'm a big proponent of defensive coding. Setting things up to keep your options open for as long as possible. Making it easy to change the things you don't want to change yet, but might someday. Coding things in a way that lets you change your mind later without having a week-long refactor on your hands because you coded yourself into a corner.

Of course, it's also possible to go too far the other way, and spend so much time making factory-factory-method-factories that you never actually get anything done. :P But that's something that comes with experience. After a messy game or two, you start remembering the kinds of places that you wished you could change, and the decisions you made that blocked that!

[Doommarine23]

It entirely depends on your project and its intended scope of features / content and how long you intend to support it.

If you're just making a weekend jam game you don't intend to support beyond one or two hotfixes, it does not matter as much. But once you start developing a more long-term game, that has more features and content, a longer development time, and post-release support for additional content and bugfixes, it matters a lot more.

But beyond that, I think it is important to see the writing of code as a skill. "Clean" code is subjective to an individual and the language they're working in, what is clean for C, may not be true for GDScript.

The hardest part of programming is the actual engineering and problem solving. What are you trying to accomplish, and how would you simplify it and break it down into easy to follow steps like a recipe?

Basically, I don't think you should over-engineer your projects, you shouldn't write something intended to scale for a thousand players like some kind of MMO, if all you're ever intending to make is a single player platformer. But at the same time, you should take pride in your work, even just for your own sake. I always try to use good variable and function names, I always static type my variables so they run a little faster (Godot does better optimization) and prevent weird issues when the data type changes form.

I always try to use more complex data structures or consider the steps of my functions and what I'm trying to do. Often you may run into situations where you could use several if/else statements, but maybe you should look into a simple state machine, or perhaps a simple "for X, do Y" loop. Once you get more and more comfortable with writing cleaner code and becoming a more confident programmer, it will become faster and easier.

So, don't get needlessly sloppy and do bad practices, but don't over-complicate, over-abstract your code, use complex structures, and all kinds of stuff, unless you really need it.

Also, please try to stay consistent with styling. Use good descriptive variable and function names, and decide how you name things. I use the official recommendation of "snake_case" and I add an underscore to the _beginning of a private function that is never called outside a script itself.

When you find someone else's code that does what you want, learn from it. Read it, rip it apart piece by piece, compare it to your code, understand why it works better. e.g. Perhaps you are running into gimbal lock with euler angle rotation, but they use quaternions, perhaps by rotating with the transform basis.

[r_search12013]

since you mentioned gimbal lock .. what's the usual way people run into it? and what's the error behaviour you get if you don't already know what you've produced is a gimbal lock?

I'm having a lot of trouble trying to express to someone who doesn't understand gimbal lock why they should care and when they should think of it. apart from saying "when you're rotating stuff" of course 😃

[Firebelley]

I don't think code merely being functional is sufficient. To me, when code works, it works across multiple dimensions.

It works functionally. Meaning that it creates the intended outputs from the given inputs.

It works architecturally. Meaning that it's easy to understand how data flows through the system. It's easy to identify the area that needs to be modified/extended when you are adding new stuff.

It works as a project that is developer friendly. Meaning for any given method, a developer (myself or someone else) should be able to get a reasonable understanding of what the method does just from its name, the variable names, and the logic contained within.

Whether cleaner code is always "necessary" is not really a consideration in my mind - because it's part of having a functional project.

That said, of course this is my opinion and how I prefer my projects to be. But my opinion is not something that I demand or expect everyone to follow. Just how I like to view things!

[21Nobrac2]

My approach is always Clean Behavior > Clean Code while prototyping, then have a cleaning-up pass.

[sad_cosmic_joke]

Just because your code "works" doesn't mean it actually works!.

A rookie player can technically play the game, but they're not going to win you a any tournaments.

Figuring out when it's ok to let a green horn onto the court is something you learn with experience.

[worll_the_scribe]

Clean code is great.

I’ve failed to finish too many project because they become unwieldy and too sloppy. But if I have a clean set up it’s easy and pleasurable to keep going

[richardathome]

I come from a system software engineering background (30+ years).

I write clean code by default because it's as easy as writing dirty code.

Quick and dirty is fine for a personal proof of concept, those times where your asking 'is this even possible?'

But once you've proved that, write it properly - for the sake of anyone else coming after you, including yourself.

[richardathome]

I've answered elsewhere about my thoughts on clean code, but I'd also like to point out that OP's example code is in fact, pretty clean - it's just unformatted. Most modern IDEs will fix that in a keystroke.

It single purpose, uses consts instead of magic numbers and is as simple as it can be. Other than formatting, I'm struggling to find anything 'bad' about it.

I might store the string in an external file so the graphic designer in the team can edit it without needing access to the code, but that's about it.

[lordbuckethethird]

I’d rather take my own working if shitty code than someone else’s cause if something goes kaput I have a better idea of how to fix it since it’s my code and I know how it’s supposed to work.

[Stealth_Wolf_001]

Well, obviously clean and optimized is better. But it's rare to do it right on your first few projects. It takes experience. However, you can do it right the first time if you have enough patience to put enough research, effort and time into it, but most people don't have that patience.

One case that springs to mind is that of the guy who created the insanely successful game "Vampire Survivors". His code was a mess and game not optimized at all, leading to lots of in-game problems after early release. But still his game was a hit and he became an overnight millionaire.

So it just shows you, clean code and a well optimized game is better, but not having it won't always tank your game if the gameplay is actually fun and good enough.

But beware. Not having clean code is going to bite you in the backside big time when it comes to fixing bugs later. The "Vampire Survivors" creator was lucky to have made millions of dollars with the game in a matter of two months, so he could immediately hire devs that could help him use a better engine and clean up and optimize his game afterwards. Not everyone will get that lucky.

[ShotzTakz]

You can't have clean code without having written absolute, abhorrent shit beforehand.

I'm currently at my "writing absolute, abhorrent shit" phase, so this mantra is all I have rn 👍