The "It's bad practice" argument, and advice for beginners of C# and game design...

News & General Discussion
1

So when starting C# 3 1/2 years ago, having now worked full time on my SDK in Unity, having programmed before I started C# only javascript and dark basic pro, and countless upon countless forum and question/answer and reddit posts later over all this time, I’ve always seen this one idea over and over again, and it always gets more annoying than the last time it’s said.

I see this same quote, this same idea put forth in everything that I’ve studied, C# programming, music composition, digital painting, and language. It’s this good old fashioned quote:

“It’s bad practice to do that” or “You don’t want to form bad habits” or whatever.

For me, over these more than 3 years working with this language, it’s always been with a level of ease, and it’s always been fun on the level of addiction. I can’t put it down when I’m working on it, I’ll sit for 12 hours straight on some days solving a problem. My point is, it’s never been a ‘chore’ for me, it’s never been something I studied formally in school or had homework or a paper due on. I’ve never had a day of stress in the learning aspect of the language. That feeling of being a rebel programmer is what’s kept me feeling alive doing it, like there are all these people that are masters and gods in the language, every single time, these people that put together quadratic functions and know these advanced aspects of calculus and trigonometry. There are actual rocket scientists everywhere, and to me it’s felt like here I’m this dumbass poor lower middle America idiot working in a back room on this, finding seemingly idiotic ways of accomplishing making the computer do the things I wanted it to do, finding the most simple minded perspectives and ways of looking at solutions, I don’t mean to come off arrogant, but where the smarts I’ve been lacking I think my passion has been at full drive all the way through this, possibly part of why is that rather than learning C# alone, I’ve wanted to see that finished polished product all shiney and new sitting on a store-shelf for all of this time, and I’ve strived for that every day, I want that more than anything in the universe at this point.

Over these 3 years, I’ve learned what I need to, and yes I’ve cleaned up previous code that was “bad practice” or whatever, but I want to seriously say to anyone starting out, to be honest, if at all possible…just do it your way.

Everyone has a different individual way of learning. The best part of it for me was that you actually could go about one problem with different approaches, which actually isn’t similar to many different things you might learn creatively, programming is amazing to me in this way.

My advice, having been a beginner myself, you’ve gotta just figure it out yourself, doing it your own way, you’re gonna be exercising your own brain, no one else’s. Maybe if you keep working on the same project you’ll want to do it differently and you’ll cross that boat when you come to it, but just do it your way and don’t listen to others when they say these two statements, that’d be my advice to those starting out, setting those boundaries, for me, really helped me out.

I decided, you know what, people keep saying about static variables “It’s bad practice, it’s bad practice, it’s bad practice” like a robot, well, just do it, see if it works. If it works, it works. Yes, later on I ended up changing it, but you’ve gotta do whatever you’ve gotta do to get the job done, to get to where you want to be by your own personal effort.

People told me that using IEnumerators were better because they had less overhead than state machines, well today my game runs on state machines, and you know what it works. It’s my own way of doing things. People say “Well, it’s 0.2 milliseconds slower”, well for me it works, what can you do.

First year I just used underscores instead of namespaces, and even tried to put the code in as few scripts and classes as possible, and that was ‘bad practice’, but it was my own way of doing things. Yes, it changed later, but there’s something to be said about the creativity of it being a child/spawn of your own brain. It’s going to be yours and no one else’s, and that’s what let’s the passion flow.

Some people prefer if statements where switches might be, some people prefer switches were if statements might be, some people use only switch statements. Some people use state machines with int variables instead of enums for it’s states, sure I’ve seen that statement used again “bad practice”, but if it works for them, it works for them.

An example of a breakthrough, when I figured out that I could use nested classes/objects, and when I figured out the simple minded way of just seeing classes/object’s methods as simply buttons on the class/object, that opened up doors for me. To someone learning formally, they might laugh when they realize this was almost maybe 9 or 10 months after starting, but I learned it MY way, and when it stuck, now it’s so integrated and I’ve practiced it so much over the years that I’ve got it down, and I’ve also learned from driving forward like this how to help people out that are just starting to understand this concept early and in a very easy and simple minded way.

Everyone’s different. Think for yourself, do it your way, individualism is power in a creative endeavor. When you do ‘get it’, you’ll understand it YOUR way and no one else’s, the information will be uniquely yours, it’s your brain after all and no one else’s. And forget about how long it takes to learn, just make what you want to make in Unity today and you’ll pretty much get it if you keep at it.

3 Likes
2

This is good advice. The biggest risk to any project, but especially when you’re a beginner, is that you’ll never finish it. And often that’s because your own code gets too complex for you to understand. Many of the best practices and design patterns the gurus are trying to advance are battle-tested ways of taming complexity and reusing already-understood solutions… but those work only if you are advanced enough to truly understand them. If you’re new, and you’re trying to use those things without really understanding them (or why you should use them), it’s just adding to the cognitive load.

So my advice for beginners is almost always: do it in the simplest way possible. And whenever faced with a choice, pick the solution that makes the most sense to you.

3 Likes
3

That’s a lot of stuff. Some comments:

o It’s easy to get caught up in being self-taught, but don’t distain a good book. Sadly, most C# stuff is complete junk.

o Namespaces in C# are a bit of a mess. When you use nested classes/objects, you’re actually using the class as a namespace: myClass.mysubclass or myClass.myStatic. Static classes – those are totally namespaces. But as you note, notation like SP1_setLabel, SP1_delay, SP2_setLabel is the same thing. It’s considered perfectly fine in some languages. The drawback is not being able to put a using SP1; to shorten the name. Sadly, using’s in C# are worse than normal.

o Switch vs. if is a trick question. Listing out every option with hand-written results is bad either way. You can usually make a much nicer array or dictionary. Or use a formula (experience to next level is 100*curLevel, instead of hand-typing out every number). Sometimes a few well chosen if’s can set values that would otherwise use a long switch.

o Static variables are what C# calls globals. Looking up “what’s wrong with globals?” should give better results. It’s not that they’re bad. Globals are easier to use, but tangle things up later. Suppose lifebar code reaches into the player globals for 4 player variables. You can’t use it to draw monster lifebars. If you wasted the time to give it 4 inputs and use no globals, you could use it for anything.

o IEnumerators aren’t replacements for state machines. That’s just nuts. It’s like saying “people tell me to use a square instead of green, but green works better for me”.

o enums vs. ints for state variables is just basic planning. If you’re making something fast that may not work and will probably get changed quickly, do something quick and dirty. As it gets bigger and more stable, cleaning it up will save time later. Enums are more readable, but starting out with them for every state-like variable is a waste of time.

2 Likes
4

For me, been learning 3d art primarily last three years, the big things that slowed me down in the beginning was trying to follow best practices I didn’t really understand (or my stupid idea about best practices that actually aren’t.)

So now I say to hell with all of that - just go as fast as you can and try to learn everything on your own through failure and iteration. Consider the advice of others but don’t follow it without trying the opposite way on your own first. Too many people just repeat what others say and then nobody understands nothin.

1 Like
5

If you work on a project alone I agree with you! Just do it the way you like.

But in a team work so self called “rebels” are annoying. Leaving really bad code because they are too lazy or do not want to stick to the rules… In a team project clean code and good practice is really crucial!

2 Likes
6

That’s like saying for your own house, not believing is fine; but when renting out, you’ll need to hire professionally certified Ghost-Busters.

7

Your example doesn’t fit to what I say, because I talked about working with other people on your own game and not alone for someone else game.

It’s like having a road full of holes to your house and driving it at night. For yourself you do not have to fix the holes(bad practice) because you know where they are.
Invite other people and they probably drive straight into the holes!

2 Likes
8

@JoeStrout hit the nail on its head. The thing that software engineers will battle the most is complexity. After 30k lines of code, how are you going to remember everything? Well, if you think long and hard about the name of every variable and method and what they mean, you’ll be able to recall how hard you thought about it, even years later.

1 Like
9

Sure, especially while learning and doing solo projects, you have to do things in a way so as you don’t bury your inspiration or motivation under comparisons to others and worrying about not having everything optimized. That said, there are tips and best practices that you can get from others that may help your own project tremendously if you have the humility to learn from others, and the interest in self-improvement to pragmatically implement advice or make the decision to keep doing as you are already doing.

I’ve worked with, and have been involved in training and development with people who were very headstrong about doing things very inefficiently and ineffectively just because they can end up with a minimally satisfactory result. With some of them, it seems to come from ego, and with others, they simply never did and are still resistant to spending time understanding how and why things work the way they do. With coding, there’s a lot of bad advice out there, but once you find out who gives good advice, be open to learning from them, even if it means the way you’ve done something for two years probably ought to change, especially if you are on a team. As @ClaudiaTheDev indicated above, teams with “rebels” who are resistant to adhering to some kind of common standards are incredibly difficult and frustrating to work with.

In short, learn how you need to learn while staying motivated and inspired to actually complete projects, but stay interested in self-improving, and be open to the advice of others.

1 Like
10

But aren’t these sometimes people who insist on using “best practices”, turning what would be a 10-minute quick test into a full day?

I’ve noticed this mostly with some self-taught coders. They refuse to read anything, since that would ruin their self-taughtness. But that doesn’t seem to be the case with the OP. They’ve read other stuff, they just didn’t see the point.

But again, these rebels could be people who only use what they consider best practices, ignoring how everyone they work with does things.

11

Yep. I was suggesting that people be pragmatic with how they implement others’ advice when I said (emphasis added):

It’s not really ever an all or nothing sort of thing, and sometimes being sloppy or rough around the edges is fine when the criticality of failure is low, like for a quick test or proof of concept. For me, the question comes down to whether you are doing things the way you do because you are making the conscious decision to be sloppy or rough around the edges for expedience, or because you simply never learned or cared to learn or reject how you can do it better.

Touche with regard to seeing ego with self-taught coders. Sometimes it comes from someone who is simply following weak mentorship and just needs to hit that brick wall enough to see that they still have something to learn. With regard to the OP, I agree that based on what they say, they sound like they are a resilient learner who has sought to constantly self-improve. The gist of what I’ve been saying is in response to how they are advocating for a “do what thou wilt” sort of thing with learning to code. I didn’t express anything rigidly except that if someone has that attitude, and is not open to learning from others and challenging themselves to constantly learn and refine their technique, then they will likely end up as a mediocre coder that no one else really wants to work with, and will have a harder time doing things well because they think they already know all that they need to know. It’s less commentary on the OP’s experience and accomplishments and more on the OP’s advice for others.

True, there are different schools of thought on a variety of code-related topics. However, when you have a bunch of people working on a team where their work will be interconnected and will need to be accessible to others, there have to be some basic standards that people accept for the sake of team cohesion and communication. Anyone who’s worked on a team where work overlapped, and at least one member of the team didn’t care to adhere to these standards or procedures or requirements, etc., knows how quickly mission-critical processes or tasks can become halted because now someone else has to figure out what the heck they were doing. I’ve had frustrating experience with this and this kind of situation can translate into major, largely quantifiable monetary costs.

12

That may be a good general starting point for learning anything, but I don’t think it’s true in this case. Unity Forums tends to give bad advice: use more properties, interfaces, singletons; convert everything to a dictionary; turn everything into an object pool; start learning whatever new system Unity might next year; plus things the OP mentioned. Sadly, the way things are now, learning C# in Unity from the most commonly encountered other folks isn’t helpful.

A decent first-year intro programming book would be just great (and counts as learning from others). But that’s got the same bad information problem — the one’s commonly recommended aren’t very good.