Best practices for development

I am running in to all sorts of problems implementing even the simplest new features. I haven't much of an idea off what is making my project so difficult to make progress with.

I'm curious to know how everyone else handles this. I have pretty good OOP code that follows OOP principles and stuff but there's always things I hadn't counted on or hadn't thought of happening which is making development a pain.

I'm not doing any unit testing, does that seem like a plausible cause?

 

I'm really not certain what you are asking and your question is very broad sounding.

What is the issue you are running into? Are you getting stuck trying to code something?

There are certainly things you can do to help guide you, such as using a project management program or creating something like a game development doc that may help, but again, I'm not sure what it is you are really asking.

 

A lot of it comes with experience. You learn from mistakes and better designs come from failures.

There's a lot you can do outside of code to mitigate that though. Are you planning ahead of time on what systems and abstractions you need? Not code-wise but feature-wise. Once you have the different components separated out then you can start driving into the code design and finally implementation. This way you can see what can be re-used, what needs to be shared, etc. It helps with mapping out any dependencies and also highlights any unwanted coupling you may have.

Some tools that help with planning are: pen and paper / whiteboard, kanban board (have you tried trello to help help organize tasks?)

In regards to unit testing, it certainly would help improve your code quality but that's on an implementation level. It will help you design well defined, clean, and de-coupled classes but I'm not sure if that's what you're looking for. Seems like your issue is on a higher level. If you are interested in unit testing, I did put out a tutorial (link) a few days ago on doing it for unity.

 

Unit testing does not automatically increase code quality. What it does is make refactor possible without introducing bugs. And constant refactoring is important in a large complex project as most games are.

In my dayjob I'm very test driven which means I write the tests before I write the actual code, this way I directly can spot problems in the requirement etc. Also if I get tasked with fixing a bug in someone else's code that is not test driven I always write a test that can reproduce the bug before I start fixing it (red/green testing).

Though it's much harder in game Dev to be fully TDD, we have some tests that test our custom network library, we also test base components that are the corner stone of our core mechanics, AI and custom room navigation, flanking, flushing etc.

Look into composition over inheritance, it tend to lead to clean and maintainable code. Also creating good agregate roots and concern boundaries are much easier in game Dev than business Dec, in game Dev objects are often real world objects while in the business world they are abstract.

Other than that its alot of experience, you just know what's right and wrong but look into SOLID, really learn and abrace those principles

 

Microsoft has a best practices page I believe. You should google it and check it out. Ultimately though, you have to write your own version and stick to it. Its also a good idea to keep up on what is considered best practices according to major software companies such as Google, Microsoft etc. A personal best practice for me for example would be to try to write everything or as much as I can via code and not depend on "drag and drop" methods for Unity. However, everyone has their own ideas about this topic. Its really what works best for you and what you understand best. The question is very broad & option to arguments/opinions. Best suggestion, do some research on what is best practices and create your own.

Microsoft:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions

Other Sites:
https://www.c-sharpcorner.com/article/best-practice-of-write-c-sharp-code/
https://www.codeproject.com/Articles/118853/Some-Best-Practices-for-C-Application-Developmen
https://stackoverflow.com/questions/2787035/coding-guidelines-best-practices

 

Maybe you don't spend enough time planning? Do you like to dive in right away?

 

Well, that's its primary use.
But unit testing can also help to re-evaluate design decisions.

This applies to a wide range of issues, no matter whether there's a general design flaw such as a critical mess of dependencies, an overly complex type implementation and/or violation of responsibilities of a class, or messy call chains inside the internal structure of a seemingly well written and easy to use class - just to name a few.

One may say code analysis tools do that job, and that may be true. But they often lack to illustrate the actual problems. In contrast, whenever unit tests have to be written - you'll recognize whether it's easy to write the test or not. Tests that turn out to be difficult to implement or to set up can be an indicator that there's something fishly going on.

@OP
Perhaps you can add an actual example. Describe one of your existing systems and its current features, and tell us which new feature you'd like to add. Try to elaborate on the difficulties and/or your concerns.when you try to integrate the new feature.
There are plenty of reasons why integrating new features and systems can be difficult, perhaps the community can identify some of these.

 

At the request of @Suddoha here is a general description of my current project:

I have a base class for destructible/poolable objects called 'Mortal'. Everything that can be spawned or destroyed with a pooler descends from this. I believe I've followed the essential OOP principles for this.

I have a number of child classes of the 'mortal' class, namely: Projectile, Ship, and Weapon.

I am presently working to implement FSM based AI. I have two classes: 'Condition' and 'State', which have the necessary fields & methods for transitioning to the next FSM state and a necessary Tick() method which may be run at a custom interval.

That's where I am having trouble.

The FSM sort of works. Whats happening is weird things I never thought about. Ie. my radar trigger field is getting called on other objects with no Mortal descendant class attached to them. I've since disabled interactions between those objects and my trigger radar.

Ie. things are happening organically but I don't know how to rule those things that are not desired out...

This might be a personality thing too. As someone asked me, do I just jump right in or plan things?

The truth is in the past I never planned. I just sort of sat down and codded whatever seemed cool. I've realized that's an easy way to get nowhere. So I planned my FSM class and stuff to operate correctly. I've been planning this AI feature for weeks. Maybe I've not spent enough time or done enoug thinking about things.

 

There is no magic bullet to fixing "running in to all sorts of problems implementing even the simplest new features". Even experienced coders run into this problem, and it's no surprise. There are, theoretically, an infinite number of ways to do things, even in a narrow field like programming. Amongst that wide list of possibilities, I think most people understand intuitively, most will lead to a tangled mess. This is chaos at work. It's how nature works.

That said, as self conscious beings with the ability to abstract, we have the incredible ability to reflect, abstract, visualize and change our behavior. Your own ability to do this is mind boggling enough to consider, but what's really staggering is our ability to do this together, as a culture.

Across the 80 some years we, as a species, have been exploring computer science, there have been some insanely bright minds who have analyzed countless projects and found something of a "local maximum" in terms of principles that guide us towards a code base which is easy to understand and easy to change.

With all this as background, and my own experience to boot, I say that people who tell you there is no such thing as "best practices" or that they are endlessly debatable do you an unbelievable disservice.

Unfortunately, there is no end to the amount of content -- and worse, opinions -- you can read on the subject and it is, imo, more harmful to chase down every suggestion. The available data has become so vast, it is more work to sift through the weeds in search of information than to just muscle your way through the spaghetti.

None-the-less, I have found, where there is agreement amongst a few bright minds, there is often fruit. So in the spirit of your topic title, here are my top picks for best practices. Note these are not, what I would term, "tactical" choices such as naming conventions or specific techniques. These are more like principles to aspire to, things you should know but not necessarily use all the time. I assume others will chime in and I leave it to you to choose the best suggestions.

1. Understand the SOLID principles. And I don't mean just look them up and know them. Understand them. Easier said than done sure, but if you constantly challenge yourself to step up to what they tell you to do, it will come in time. To start, read the explanations from the original author: Clean Code. After that, the first 3 sections of Dependency injection in .net. This one will probably come as a bit of a surprise to people but I think it is an absolute GEM. If you don't truly understand the D of SOLID, this one will turn your programming world on its head.

2. Understand the difference between inheritance and composition. Something of a pattern starting here.. Yes, understanding is the key. I've met many a programmer who either can't explain the difference or can't explain how to choose between the options. I, unfortunately don't have a good suggestion for formal reading on the topic, but you can start here, and wait for others to chime in.

3. Understand error modes. Your code will do bad things, and you need to have a mental model of what that means and how to handle it. Unfortunately, this is something of a highly contentious topic but I don't believe there is any good reason for the controversy.

4. Learn your domain and focus on that. If it's games, then read game dev blogs, find books about game dev, extract every piece of information you can and then take time to reflect and abstract it into a mental model. When you're ready for a challenge, Domain Driven Design is a beast of a book that is not only well recognized in industry but also dense with useful design ideas and, more importantly, processes.

5. Commit yourself to the field. Perhaps a self evident point but, unfortunately, one that many people skirt. If you want to be serious about being a programmer, you have to see it in the light of a profession. You might have heard the "myth of the 10x programmer". According to me, it's no myth. I won't put a number on it, but there is a world of difference between a programmer who goes to work for the check, and a programmer who is in the field to make an impact. For this, I again refer to Robert Martin: Clean Coder, though there are many other avenues to achieving this mentality. Make more time for reading, it makes a world of difference once you're in the industry.

 

I just purchased Clean Code by Robert Martin. Its already a fascinating read!