11 tips for writing cleaner code

[@Airaldi]

For those trying to improve their code quality/style i can recommend the "Linux kernel coding style". For functions it says for example: "Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well. The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it’s OK to have a longer function."

[@Sylfa]

For the "shorter functions" section, a good rule of thumb is that the whole function should be visible in your editor at once. Another good method is to look at the number of decision points, each if/for/when has two paths that the execution could pass through, true/count>0 and false/count=0. This was dubbed the Cyclomatic complexity, and you should attempt to keep that as low as feasible, originally it was suggested to keep it under 10 paths through a function.

[@Dahras1]

Great video and I totally agree with most of the points! One thing I would add, however, is that there are major pitfalls to preferring smaller functions. While lots of smaller functions can make a function more comprehensible at the high level, they also tend to have the side effect of turning the sections of your code into a black box. I think the example in this video shows the problem perfectly because the functions that compose determineNextFunction don't exist on an island, each one depending on data from previous functions in order to work. As such, if there is a bug with this functionality, you pretty much have to read all of the functions together as straight line code anyways. Of course, the function-ized version is less intimidating to read for readers. But the more digestable format obscures how the code actually works. This gets especially bad if functions are nested. Obviously, using functions for reuse and in the case where something like _process is doing a couple of completely discreet things makes total sense. Moderation in all things . But in my opinion, if you are doing a bunch of sequential steps that feed one into another, and none of those steps are planned to be done elsewhere, it's much better to just keep things inline and use comments/whitespace to make code "paragraphs". If you need to reuse some of those paragraphs in the future, you can turn them into functions then.

[@TheShaggyDev]

Totally valid points, and I think that you're right that my example isn't necessarily the best for getting the point across - the pains of trying to come up with an example small enough to show in a video but large enough to demonstrate a solution! It's not easy to talk about larger code subjects when you can't show too much code in a video without people's eyes glazing over, so this is good food for thought on future content... Regarding function size, though, I certainly write larger functions if all the pieces are interconnected, as you mentioned, but I call out smaller functions specifically because I commonly see newer developers throwing everything into their update loop or initialization call or whatever, so I think a lot could do well to start with a rule of thumb of thinking smaller and then naturally figuring out how to relax that rule as they get more experienced and develop a better natural code style. This one combined with the tip about functions doing one thing is all about trying to get people thinking about why they're writing what they're writing and where.

[@Dahras1]

@@TheShaggyDev I totally understand and I can only imagine how difficult it is to make these more abstract tips fit into a video. I see your point about beginners putting everything in _process, and that's definitely way worse than over functionalizing. Thanks for the comment and, again, great video!

[@TheShaggyDev]

Glad you liked it! And thanks for the conversation. All good points. KZbin can be a bit one-way so comments like these help me (hopefully) refine things over time :)

[@nambreadnam]

I usually approach DRY slightly differently. It's more like "Don't repeat yourself three times" since it usually takes me until the third time writing out a similar section of code to understand how it should be refactored, what interface it needs, etc. Otherwise I spend more time deliberating on a function's interface than actually coding.

[@badunius_code]

Same. Extracting a code snippet before its third repetition is premature.

[@Heavypoly]

Every one of your godot videos is pure gold....thank you!

[@TropicalMelonMan]

This is great advice to stick to, imo, and it's generally how I do my own work. I've always wondered about code architecture in Godot, since it's not something I've found much info on yet. I can't remember having seen much code that wasn't littered with tight coupling, global state, awkward hacks and so on. Every game-engine is a unique framework and often calls for specific ways to handle architecture. Scalability is crucial in any project larger than your typical super basic game- the alternative is a one-way trip to sphagetti-town real quick. I'd love to see your take on this topic later down the line. Great vid! I appreciate the way you explain things clearly and how you always provide examples.

[@TheShaggyDev]

Glad you liked the video! And I agree 100%. Like you said, bad code samples are commonplace online and resources on structuring your projects are hard to find, which is a shame considering how quickly, and often, game code becomes a mess. I think it's because it's a challenging, unsexy subject when what you really want to do is just create something fun... until you have to spend a week undoing sloppy code.

[@RobertoMaurizzi]

"The most important code metric is WTF/s" :D

[@javgroman]

Not Invented Here. Very helpful tip.

[@Ignawesome]

Amazing video, as a beginner, it really helped me understand how to write code in Godot, although I still struggle with architecture... How many managers should I make and should they be autoloads? It depends on each project but I'd love to see some pro tips for that.

[@nyuh]

Nice vid. I think it's time for me to do some spring cleaning :) PS: I look forward to the video on code architecture

[@9trx]

Very good video thank you so much, i'd like to see more content similiar to this instead of just spesific game engine focused ones. Please make more code architecture videos.

[@TheShaggyDev]

I intend to! I've got some more Godot videos in the works, since there's always more to talk about there, but I'm also going to start putting more focus on broader development topics, including more videos on programming and architecture among other things that I'm still deciding on...

[@_gamma.]

Great little video! I do think relying on ijk are also a bit of a smell since most language have proper iterators now, I very rarely use them (and I usually still name them with some version of “index”)

[@TheShaggyDev]

Very true! I also tend to name them something like "index" just to be a little more descriptive.

[@TheMashmeister]

Basically in my exprience. keep it clean keep it simple. do not over engineer. make your code reusable. dont name your functions stupidly everything should explain it self very well. Minimal comments only and if they are needed to explain something. but make sure that this comment wont get outdated. and the list gos on and on and on and on... and what each company "Project Manager" Considers best practice will greatly deferrer from one company to another.... I really would like it if one constant was kept. but us developers are aholes ^^

[@green0ne40]

Thanks!

[@TheShaggyDev]

Thank YOU! Glad you liked the video!

[@GDScriptDude]

What do you think about declaring script vars just before functions that access them rather than near the top of the code? I think that you were doing that in one of your examples and it seems like a better idea to me unless they are export vars.

[@TheShaggyDev]

Not a fan as it can make it harder to understand what variables exist and what your code is doing. It only appears I did that in this video since I showed some code snippets side by side, but in a full script I always declare my variables at the top. Plus, you never know how relevant that variable declared in the middle of your code may be down the line...

[@GDScriptDude]

@@TheShaggyDev Good points, thanks.

[@gauravkumawat5811]

Where you've been Sir. I desperately needed a teacher/ mentor to help me learn Game development using Godot. God bless you sir🙏🙏🙏🙏

[@brentsteyn6671]

People check out object calisthenics. There is one rule that I find superior to all rules is: "Only One Level of Indentation Per Method/Function"

[@TheShaggyDev]

Excellent rule to live by. Definitely helps you keep your code in good shape. Wasn't familiar with object calisthenics previously, but that entire set is good advice. Thanks for sharing!

[@SaiponathGames]

Wouldn't that create more functions?

[@TheShaggyDev]

@@SaiponathGames Sure, but that's not a bad thing in and of itself. Better to have several small, readable functions than a monolithic function that does too much.

[@gauravkumawat5811]

Sir can you please make a playlist of instructing the features of Godot Engine step by step 🙏🙏🙏🙏🙏🙏

[@TheShaggyDev]

Is there something in particular you're interested in? If you're just looking for general introductory stuff, might want to check out the content from GDQuest or maybe HeartBeast, who already have a lot of beginner content available