Is this the best way to code and does anyone else do it like this?

News & General Discussion
1

I wasn’t sure where to place this thread.

The way I code, I always find myself thinking of the next feature and coding it straight in to the computer without planning (much). I consider it pretty awesome that I can work out a solution to a problem in a matter of minutes (bugs/glitches permitting, I’ll get to that…).

What bothers me is am I missing anything? I don’t usually make sweeping changes unless I can help it. I use VC for that (come to think of it I haven’t rolled back any commits for problems introduced before).

I’d heard of Unit/Integration/System testing before but I have never done one of those. At most I make certain the game works obviously. I haven’t had to deal with users entering text yet (ala chat). Literally just googled it and learned something just now.

If I run in to a serious problem with my code its either due to being really tired or just being unable to solve it without planning something basic first (a seriously tough problem). I’ve learned in school how to plan code out, and I’ve also learned that doing so makes things much easier and quicker in the long run. However I have not put this in to practice much. I feel as if my style of programming though adequate is costing me time, and a really bad habit which is tough to break.

Sometimes banging my head against the wall with a particular problem is all I can do. At some point I’ll ask for help, but that is usually after several hours or minutes of no progress.

How do you guys do it? Am I doing this in a “normal” way or just bizarre?

Its odd, my dad said he’s always been an organized person and that my siblings definitely learned it but I have never cared or organization and planning since I was very little. My room is a mess… haha

I am a quite impatient, disorganized person.

[edit] The text in bold really gave me some perspective just after writing it… gonna have to change a few habits. Start planning things.

2

When a program is being fleshed out for the first time, I usually implement featrues when the need arises… while trying to adhere to practices that will reduce amount of pain in the future. Usually, code during this time is in state of flux, meaning files get split into several, joined together, functions are moved around, classes renamed, etc. Sweeping changes are common.

The idea is to do what I can to avoid planting landmines in your code which will backfire badly in the future and at the same time keep readability high. Things that result in landmines… those were learned through practice, and from occasionally disastrous msitakes. Readability is important because in two months you’ll most likely forget how the hell the program worked to begin with.

The main important principles are YAGNI and KISS.

https://en.wikipedia.org/wiki/You_aren’t_gonna_need_it

Kiss means that solution should be as simple as possible.
Yagni means, that when you don’t need something right now, you shouldn’t waste your time implementing it. Meaning any feature you implement should provide some practical benefit RIGHT NOW. If it doesn’t do it, but falls “it may one day become useful, maybe”, it is a waste of time.

Aside from that it is mostly adhering to various practices and guidelines.

Basically… problem solving is the easy part. The hard part is keeping system working and operational at all times, even when it undergoes major restructuring changes due to a new feature request nobody saw coming.

The fun part is when you have a big piece of program code you wrote (from scratch over course of several months) which needs to interface with code written by someone else (written from scratch over course of many more months), which, utilizes several third party libraries (that dwarf both projects), it is beyond toy problem category (toy problem is something under 200k of code, IMO) and now this thing need to be restructured from the bottom to the top level because new feature requires a radical change in that one class that just happens to be root half of the class hierarchy of the project When stuff like this happens, it is FUN (In Dwarf Fortress definition of “Fun”).

5 Likes
3

Really depends on the complexity and criticality of the code.

If I’m designing a simple game system (non complex and non critical) I’ll just jump into code.

For a complex game system (complex and non-critical) I tend to box things out on paper first. With general lines showing flow and interfaces.

For critical code (process automation or business software) I’ll go into full blown planning mode. That normally includes stakeholder requirements, plain English descriptions, drawings, edge case studies, peer reviews, offline code testing, more peer reviews, online code testing, and so on.

2 Likes
4

Get something functional first, then polish later. That’s the way I like to do things.

It’s much easier to inch toward a better solution from suboptimal implementation, than it is to get things exactly right the first time. And doing it this way develops better instincts and reflexes when it comes to arranging specific parts of code etc.

3 Likes
5

Even if i don’t always plan on paper or with some UML tools, depending on the complexity / size, i still plan ahead to be able to easily expand and add functionality to whatever i’m coding. Trying to follow general good practice so that whatever system i’m coding can be added to other projects.

Did you ever try to draw without knowing what you want to draw in the first place. Well usually the result if pretty bad, it’s kind of the same :slight_smile:

It’s not much harder to code something “well” than “just make it work” and it will save you ton of time later, cause otherwise, more often than not, you will leave the dirty code and issues will rise at some point. If you work in a team or for large projects, feature are added / remove very often, and you absolutely want things to be well program so feature A doesn’t break feature B C and D… XD

I liked uFrame for the possibility of planning within Unity sadly i don’t think it’s being continued.

Using frameworks like Entitas is also a good way to keep things organized, clean and modular.

6

For complex systems, I normally plan ahead by writing down all the important concepts as interfaces/traits and try to figure out correct hierarchy and relationship between them.

In other words, I always try to start from the top, and go from the most abstract concepts down to the most concrete implementations.

I suppose the whole point of OOP is to hide all the details until you get the clear idea of your system as a whole.

1 Like
7

I have coded for over 30 years. What I have found is even a small amount of time spent planning can result in a very large amount of time saved coding. This is especially true on very large coding projects.

At the very least, take some time to make a brief outline about what you plan to code. This gives you the chance to really think about the structure of the classes, and it is very easy to make quick changes to a simple written outline. The outline can be as simple as some text notes in notepad, an actual outline in Word, or UML tools.

Jumping straight to coding (without planning) can save a few minutes up front, but can cost hours or days further into the project.

1 Like
8

Often, I’ll bring up notepad++ and type out the problem, and the objectives also. Then, I’ll start typing out various approaches and such, very often this helps me arrive at the direction I want to go.

1 Like
9

I just make it work then spend a while fixing/refactoring later.

For me, this is a far more important task than choosing the right pattern to use, since refactoring something that works is always easier than designing the perfect thing before you make it.

5 Likes
10

Very true! I think experience and history shows that designing the perfect thing at the start…isn’t realistic.
And I think one of the benefits of experience is gathering having more tools in your tool belt or options that you are aware of, to solve technical challenges. It doesn’t necessarily mean you start with the solution already laid out.

1 Like
11

I tend to just work with notepad++ open to help keep track of notes as I go.

Most of the logic you need in games is fairly simple, as long as you aren’t killing yourself with infrastructure it shouldn’t be hard unless you need to deal with large team coordination.

The more clarity you have in terms of what you want to accomplish, the less organization you need. If you have a firm grasp on the problem, the code writes itself.

Having clarity on your goals can be quite challenging though.

I think the most challenging element of game code specifically (other than clarity of purpose) is dealing with many, many subsystems interacting. Game code tends to have more writes than most other code, and if you have many systems writing to the same data it can be tricky to coordinate.

For instance, a complex character rig can include the physics engine, animation system, input system, interaction with game geometry, ai navigation, and pure cosmetics all working at the same time on a character mesh.

1 Like
12

I usually tend to code at two levels, broad view design and architecture, so trying to define the overall functionalities and scope and low level prototyping code, iterating and improving several times the single code part until I am happy.

In Unity I use components and interfaces a lot as this is I believe how it is meant to be coded…

13

I do it pretty much the same. Anything simple is done in my head, and very basic outlines are done on paper for harder tasks; generally just a list of the functions I need a class to have so I don’t forget when I’m programming it. The only time I actually write down code is if I’m bored/have a great idea in school and can’t access my laptop.

14

Hmmm… interesting. Do any of you guys use unit tests?

On a related note… ahh crap I forgot in the midst of reading all of that. It was kind of important.

15

Tried them once. Don’t think I’ll bother again. Unit tests are great for relatively static code with clear requirements. Game code doesn’t tend to be static, nor are the requirements simple.

Thus I find them mostly a waste of time.

2 Likes
16

I honestly can think of ideas like ‘Okay I want a Jetpack’ and just already know what I want to make in detail.
Maybe not 100% detail, but at least 80% of what I want to make has already been thought of in the moment I thought of the idea, then the other 20% of the idea is left towards creativity and trying new things.

17

It’s almost thought of as a ‘blasphemy’ these days, if you deny the value of writing unit tests. As to TDD, the opinions are more divided though, and there have been series of debates on the usefulness of the practice.

Personally, I can see the benefits of writing unit tests and try to write them whenever I can. But I think those people who argue things like “Writing unit tests actually can save your development time” to be kind of deluded :sunglasses:, so I usually take a pragmatic approach and only write unit tests for those cases where their value surpass the cost of writing and maintaining them.

I beg to differ with @Kiwasi in that regard, though, as I believe those types of code which tend to change a lot often give the greatest value when it comes to unit testing, because one of the most important reason to write them is to detect regressions early so that make it easier to refactor existing parts of code.

And writing unit tests often make a complex requirements clearer, as can be seen by the fact that they are often used as replacements of, or supplements to actual specifications.

There’s little value in writing tests for such code which rarely changes, or seldom gets affected by other parts of the codebase. Automated and repeated tests only make sense when they can detect defects frequently.

So, I come up with a pseudo formula which can be used to estimate the value of writing a unit test for a certain part of the codebase:

Probably the only reason I can think of, aside from shortage of development time, for not writing tests for a game project could be the inherent complexity involved in testing it. However, it seems that Unity has been evolving rapidly in providing better tools for writing unit tests recently, so I expect things would get much better in future.

Even as it is, I found it to be quite easy to write unit tests in Unity. And even with some rough edges in the test tools, it already helped me find corner cases and catching regressions in many occasions. So, I highly recommend to write them whenever you have enough time.

2 Likes
18

It’s entirely possible I’m missing the point of unit testing altogether. I’ve tried to grok it on my own, without a meaningful guide.

Do you have any good resources on the practice?

19

I tend to disagree, strongly even. Well maybe I should qualify…

Unit Tests are terrible time wasters when dealing with large and significant changes, they’re amazing when dealing with small changes, fixes or extensions.

If your requirements change dramatically for example, most Unit tests will need to be thrown out, and the time writing and maintaining them is lost time.

If the work is more maintenance style work, and change is limited, then testing is golden. Since most work is maintenance style, tests make sense and provide safety from risk. It reduces the chance of major regression between minor releases or patches for example.

Many of the best practices in the programming world revolve around providing additional safety in terms of smaller or mid-scale changes at the cost of additional difficulty as the scale of change increases. This makes sense in most programming environments, but certainly not in all.

20

I’m sorry that I cannot recommend you any specific books or articles. But it’s been a while since unit testing in general has become a common practice in many different fields outside the gaming industry, I believe there are many good learning materials you can find on internet these days.

Probably, it might be a good place to start if you can find some guide or an example of TDD practice. Even though I don’t like TDD myself, it seems that those people who follow the practice are the most ardent supporters of unit testing, and the fundamental concepts are still valid even if you are not strictly following TDD to use unit testing for specification.