Bad Code Practices

Unity Courses Talk
#1

I’m having a nice time on game dev tv but I find out in this course they are doing horrible code practices that we shouldn’t do.

  1. Make the variable public rather than make it private and change it using a setter.
  2. using true and false rather than using the Event system.
  3. using unnecessary if-else Statements.

but It’s for beginners so It’s okay to make sure to learn good code practices too.

#2

if I would’ve seen that on my first day of learning how to code, I would’ve thrown the course out the window :sweat_smile: (scary code terrifies me, but I’m learning as we go, xD)

It gets better though (idk about their 2D Courses, but I know some of their other content is pure gold)

#3

It’s not about the course either.
I have a software Engineering background.
So it just makes me feel kinda odd.
but their teaching approach is great.
NGL good quality codes depend upon the developers rather than the platform we are learning.
I love this community learning a lot.

#4

I think I read this somewhere before, but from time to time they’ll set you up with bad code practice that purposely fails, just so when you get to use good practice down the line, you know why you’re doing this

Eventually it gets better

#5

Please let me know if I am wrong, but I don’t think that’s the case in Unity/C# codes.

#6

yes here few instructors write great clean code and others write evil code.
I understand It’s just a tutorial but here we learn how to write production-quality code.
But In the c# intermediate course, they chose good instructors like Code Monkey, DinoDapper, and others. So If we spend more time on their course I think we can overcome our Spaghetti code.
It’s up to us how we learn everything is great when we learn then become a good developer It’s mean to be that way.

#8

Not sure I agree with your examples but good discussion to have. Some thoughts:

  1. There’s no point in having a property if the member genuinely needs to be accessed outside the class without validation or other side effects. It’s not more encapsulated because you route modification through an accessor. Just adds overhead. Might be something worth adding later, until then YAGNI applies.

  2. Events have vastly more overhead than a Boolean flag, YAGNI definitely applies. If a piece of code is already modular, scalable, and reusable, converting it to use the Observer pattern is just cargo. With that said, you might enjoy the upcoming lectures where Sam does teach an intro to dependencies, inversion of control, and other software engineering entry level topics. He’s a proper SE, but we do have to appreciate that anything more sophisticated would be out of scope for this intermediate course.

  3. Many developers would politely disagree with you on this one. The course generally tries to follow the principal of self-documenting code. Descriptive locals make code more readable, which has concrete benefits for debugging and collaboration.

It’s really a case of following YAGNI. The course is genuinely quite a brilliant on-ramp in my view, especially for a solo developers first game.

——

Outside the examples though, I do agree with you in principal that it would be nice to see a more advanced course on real full scale game production architecture.

Until then, advanced learners would be well advised to:

  • watch some of the legendary GDC talks on ScriptableObjects as logic assets (Richard Fine’s original talk is great, and Ryan Hipple’s was groundbreaking).
  • dig in to the UOP1 demo and read through those development journals / forums. (Closest thing we’ll get to Gigaya).
  • read the Unity official ebooks on programming patterns and game architecture

And be aware that other “best practices” channels like InfallibleCode coming from an enterprise background actually don’t align with what Unity themselves suggest.

Until then, I volunteer to put together a course for GDTV on the eternal “inspector dependency injection vs. C# dependency injection vs. Find service locator vs. C# service locator vs. SO Singleton vs. C# Singleton” debate and Unity’s official answer for best practices (ScriptableObject based EventBus architecture with custom inspectors) later in the year. :slight_smile: @Kevin-Brandon / @Brian_Trotter do you know if anything like that is already in the works out of curiosity?

All this being said, even Unity hasn’t dogfooded a real game so hopefully one day we get a book from a III who has released a big game.

#9

That’s actually one of my greatest pet peeves, when I approach code that says

private int _myVariable;
public int MyVariable
{
     get {return _myVariable;}
     set {_myVariable = value;}
}

All that’s been done here is that you’ve added two new methods to the code, you have not solved the underyling issue of variables being set directly from outside of a class. For that, you want a private setter.

Groundbreaking. I remember a lot of debate at the time. Some folks (raises hand) thought it was brilliant, others thought that SOs should be for data only, and should just be glorified structs.

Even Design Patterns by the Gang of Four don’t always line up with Unity’s architecture at times.

We have a survey (beginner) course on design patterns, but while I’ve been wanting to put something together along these lines, I don’t know that we have anything like this in the works.

Privacy & Terms