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

Code smells are things in a codebase that readily stick out and imply something may be off with how it has been designed. Here's a few common ones you may find in your own codebase, why they can be concerning, and how to fix them.
Text version: shaggydev.com/2023/01/16/code...
Martin Folwer on code smells: martinfowler.com/bliki/CodeSm...

[@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.

[@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!

[@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.

[@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.

[@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?

[@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!

[@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.

[@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!

[@iAmCodeMonkey]

"Easy to maintan" *maintain ;)

[@TheShaggyDev]

Words are hard sometimes 🙃

[@jungsa4691]

"Don't Overengineer"... oops.