A few common code smells to be aware of and how to fix them

[@Bargeral]

Great advice! Coincidentally, I just refactored some small bit of code I was having issues with. Putting all the bits into separate, well named, functions made a huge difference in readability and in turn made troubleshooting much easier.

[@DevDev-dm3st]

Great video! Remember though, you don't have to implement all of this immediately, it's usually better that you release a software/game and get better iteratively. Do note, that this kind of things are great for longer term projects since bad code will always follow you around and reducing that as much as possible is needed for making those bigger games.

[@kiyasuihito]

Your channel is super underrated. 🎉🎉

[@GenericInternetter]

2:27 i cannot express how utterly useful this screen is with these four simple lines of text. for years i have been confused and you have cleared it up in about 10 seconds of video, truly amazing work, thank you!

[@pseudo-CraftingTable]

I think this is more suitable for more experienced devs especially if they don't realize they've made the worse way over and over again. For beginners, this can be part of learning process. Great video!

[@CoreyDWillis]

Wow, my first project definitely had a few God Objects! I found this really helpful and also it sending me down other learning paths.

[@theacroguru]

I believe referencing the videogame titles you place clips from will pump ur reach

[@Ignawesome]

I'm currently struggling with the God Object thing... I know I shouldn't use it, but I don't know how to organize code otherwise, does anyone have any suggestions?

[@traveller23e]

For random functions that don't really have anything to do with the program but are potentially used all over, try creating a folder (not just a single file) called "utilities" or similar. Then for each kind of utility create a separate static class- so you might end up with files along the lines of "StringUtils.cs", "AsyncHelpers.cs" etc. (using .cs just because I happen to be principally a C# dev). Then for truly global state maybe have a static class called "ThingimagigProvider" or something, with a property "Thingymagig" which can in turn contain that portion of state. People will try to sell you on all sorts of complicated patterns to allow globally-accessible state but honestly that's all that's needed, just initialise the property once in the obvious location (maybe when loading the program, or resuming a previous session). However, I would recommend keeping the state objects either small or useful, by which I mean that if the type used to contain the data is not used anywhere else in the program, keep it as small as possible and don't add methods or anything. Then for things that require both data and logic, try to decompose them. If a particular step in the flow is complex, break it out to its own class so having ten methods that all take part in doing that basic task plus any supporting properties isn't an issue. As an example, I recently made a "basic" program that compared data from two sources and allowed the user to do some very basic operations. However, loading from each source was a complex task so I ended up with a loader class for each source, a coordinator class to call the loaders and when loading was complete do some additional operations like comparing the data, as well as managing some tasks that involved both datasources. Then there was a viewmodel for each loading source to manage the UI-related stuff (bindings etc), plus a central viewmodel, and finally a global static class to hold a single property containing the configuration essentially. Finally there are some operations requiring a bit of logic + API calls, and that's also in it's own class. My rule of thumb is: if it doesn't fit neatly anywhere else or if you're having trouble keeping track of the things in an existing class, time to make a new class. The only time a new class is pointless IMO is if all it does is pass method calls to some other class without actually containing any logic.

[@jungsa4691]

"Don't Overengineer"... oops.

[@WhatTheHeckman97]

What's the driving/moving game at 4:30?

[@TheShaggyDev]

Radical Relocation!

[@nathanlamaire]

0:31 With an arrive of various sugar syntax implementations (especially coroutines), this is no longer a bad practice to have long functions that handle procedural processes since it reduces the need to jump around each parts of code especially for vim users, and helps tracking down problems in particular processes from single function. Still, it didn't take away the fact that you still need to break down 'common functions' that is re-usable across other parts in the module or even project and not just try to duplicate them over and over again and reduce refactoring task. I usually only see long functions as a problem when the code is written in object-oriented and the implementation goes on the 'god object' route. Godot is pretty great example because it encourages you to write this type of bad code more than you might think. 3:38 Global objects/modules aren't problems by themselves since you still need some ways to communicate between objects/modules. Unless it's on certain implementations, please, please, do not reference an entire object globally. It inherently creates hidden dependencies across two objects and increases difficulties to debug and maintain. For common practice to have global objects, it should be as generic as just having primitive and 'shareable' values, such as player score, local parameters in multiplayer games, or internal object types (since this part hardly breaks because the solution maintainers usually don't make changes on their API, but you do). Also, don't forget to break down global objects that handle particular tasks so you won't have cluttered code/god objects. If you wanted to communicate between objects, just try to use solutions provided from the tool to handle them. They usually all have 'messaging' patterns for you to follow and helps you write clean code without the need to use global objects. 4:34 Oh god, thank you for including this. I still cannot handle my feeling seeing loads of game developers trying to solve problems that don't exist with their over-engineered solutions, and sometimes also tilted or even discouraged newcomers to actually do something productive because they stumbled upon someone's 'over-engineered' solutions. Who is the problem? Nobody. People love showing off their work and there's nothing wrong with that, but it should also be noted that in many cases, you don't necessarily need to follow hard routes just to get your job done.

[@Skyvastern]

That's a great video. I have just one question. I think you use Godot as your primary engine for game development. Considering that you talked about functions that have long list of parameters, and one potential solution is to have most of these properties in a single object. So in the case of Godot from what I've used so far the classes we create are all derived from nodes, and if we instance them then they get added to the scene tree. So if this is case then how can one effectively create classes that can be later used to instance objects that can be passed as arguments without them being added to the tree, or is there something I'm missing out?

[@TheShaggyDev]

You actually don't have to always use nodes! References and Resources are two other options that are more lightweight and can serve the purpose of data containers nicely. The Reference class (docs.godotengine.org/en/stable/classes/class_reference.html) is essentially a "pure code" class that is as lightweight as you can get without getting into memory management, and Resources (docs.godotengine.org/en/stable/classes/class_resource.html) are similar but are designed for saving and loading from disk. There's a nice write-up in the docs that explains your options to go more lightweight than nodes: docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html

[@Skyvastern]

@@TheShaggyDev I have used Resources a little bit, but never used Reference types. I'll look into it. Thanks!

[@iAmCodeMonkey]

"Easy to maintan" *maintain ;)

[@TheShaggyDev]

Words are hard sometimes 🙃