Event though we have delivered quite a few projects so far, I wouldn’t describe myself as an expert coder. I can surely call myself a professional coder … but with each and every project Me and Adrian learn something new. By keeping this kind of attitude you stay humble and become open to continuous growth.

source: xkcd

You can treat this article as personal point of view of how I try to manage a poor code. Be that my poor code or the code of external project. I won’t comment or give examples from real life if they regard my clients code as this is not ethical to talk about the code of my clients. The poor code is always there for a reason and as an effect of some particular circumstances. The clue is to understand the circumstances & possibly prevent them from happening in the future.

However it’s crucial for you to understand your role as a coder :

You are here to give solutions, not create more problems or talk about them.

This might break some code purist heart but believe me or not – clean code is not the most important thing in the world. Clean air or access to drinking water is more important, for example. Staying happy and being nice to other people is also more important.
Remember that in larger projects or organizations common good or projects well being is more important than the uber-clean code. It’s always the compromise.

Your ultra – hyper – efficient method or function is no good if the whole solution is not working as it was designed.

It’s also important to understand the basics of empathy – something coders are not too fond of. You see – people generally have good intentions. It’s crucial to keep this attitude at all cost.

If “Mark” delievered a bad piece of code it may because of several factors and that he did it on purpose is the least probable one:

  1. Maybe he was running out of time or other resources?
  2. Maybe the design principles have changed?
  3. Maybe the coding pattern he used was a good solution for a similar case in other project but is not the best choice for the current one?
  4. Maybe Mark did not know any better way?

You know… engines are improving with each and every iteration. Back in the old days you would write a function for an object path. Now you could simply use an Animator component in Unity which is more efficient and less time consuming. This is just a simple example.

Projects do have certain scope and deadlines. Some are managed quite OK some are managed in less perfect way. Sometimes design changes in the middle of production. As a coder you must adapt.

And it’s hard… I know it as I’m not saint in this matter as well. Sometimes when I see poor code I tend to curse quite a lot. No one likes having more job than it was assumed and you can always be sure about one thing in regards of poor code: It’ll bite your bottom in the times you least expect it.

It’s called Technological Debt for a reason. The big and ugly fellow who collects it is called “The Crunch” and no one likes that bastard.

That’s why in larger organizations or projects you have code architects and mandatory code review and unit tests.

I may sound here as a know-it-all guy. I’m far from that. Now I simply understand more the friend of mine who had done some code review for my projects when I was just starting my career as a professional coder.

Generally – the more time you spend on designing the code before you actually write it, the better it is for the whole project.

But what happens when you do not have such comfort? What to do if you get the code and the first thing that comes to your mind when you see a code is

” Who the heck wrote it? What was that guy thinking… I don’t even…”

I admit I do this all the time… sometimes I say it out loud… and its counterproductive. I wrote this article partly to learn how I can cope with that so I can be a better professional.

Set your current priorities right

Do you have to chase the time to deliver a usable solution for an expo? Is your deadline near? Are you running out of money?

You have to deliver. Sometimes at all cost.

General tip:

if (it is working)
   Do (not touch it);
else
{
   Make (as few modifications as possible)
   Or (it will stop working at all);
}

This, however, in many cases makes the Technology Debt even bigger. It will hit you even harder. I had this situation when we were coding Futurust when at around 4th milestone we had to stop and refactor almost the whole game. We crunched until 4AM for a week days and in the end I and Adrian got sick out of exhaustion. I promised myself never to do such a stupid thing. However at that time we had no other options. We were running out of money and in combination with publisher not being the most reliable financially partner we had no other choice. Either we crunch or we starve.

REFACTOR

This does not mean that first thing you do when you see a poorly written code you must rewrite to fix it. First you must understand the whole scope of the project. This is specially my favorite type of mistake I tend to commit too often. I see a switch – case condition for 200 lines and I get this urge to just delete it and write it from scratch in a proper way. This is this quirk I got after reading “The Clean Code” book which I strongly recommend to any coder. After reading that book I became almost a new-born code purist fanatic, a radical in purity…. and as all sort of radical solutions… it may not be the wisest of choices if you come and think about it in a long term and in wider scope.

Instead I recommend to do it piece by piece, class by class, write unit tests as you go and refactor, test the whole project each time you make a change, use a safe branch and merge only if you are 100% sure it will not break the whole project structure.

I remember once I saw a code moving some GameObjects on a scene in a loop. I had to prepare it so a non code oriented person could add some sounds to the whole loop. First thing I did was remove the darn code and substitute it with animators. It’s easier to add animation events to animation files for a designer than to read through a large class to see where should you invoke a method you need. I made a mistake thou. I erased the whole class. I thought that since I was not using it I could simply delete it. Well … not going into details … there was another class that, even though did not create an error when I deleted the class in question, depended or invoked a method in that class. One could argue who was right or who was wrong but the point was that my change, even it was more efficient, broke the project. I did not know the full implications and the whole code base. Poor or not poor – make sure that patient will live before you decide to extract the cancer.

Instead try to layer or make the code more modular without changing it. This leads to some reduction of interdependence.

Before doing such a critical change it’s better to team up, discuss designs, principles and solutions. It’s not possible if everyone’s busy with delivering the build… but sometimes this has to stop… and this is a good time for HAMMER TIME 🙂


source: giphy

COMMENTS

Here’s another tough one for a purist as me to understand. I was tought that a pure and clean code should be understandable without any comments. How about if this is the only way to understand this madness?


source: xkcd

Sometimes comments are the only choice to find a way out of this maze.

Final Summary

As I mentioned above: I’m not an expert. I do mistakes all the time. However I do remember one thing always – making games (and that means coding games as well) is fun.

Let’s keep it that way.

Being an a-hole to your team member or proving them you are right or proving them wrong does not help the whole team. In the end you and the rest of the team should be proud of the final result and you all should push toward the final release. If that means leaving this few bugs or losing a frame or two on the efficiency leave it as is. Friendship and having fun is more important than a code purity.


source: devhumor.com