I’m fairly active in the Unity community, both locally, and online. During my time working as a Unity dev, I’ve seen some bad code, a lot of horrible code, and some good code. I’ve been been lucky enough to feast my eyes upon some great code. The tips that follow are merely based on my observations and experience.
I’m by no means a programming god, and these are not commandments, but I’ve found some success in following these tips. Hopefully some of you can find these helpful as well.
Without further ado, let’s begin:
#1 – Don’t fight Unity*
This one is a bit broad. However, I run into this when developers are coming to Unity from other development environments. While Unity is fairly flexible, there are certain design decisions that are at the core of the API and the engine itself, and fighting against that tide is generally a losing proposition.
*Unity has made some truly baffling decisions in certain areas, such as Input and Pathfinding (no API), among others, but these are features, that you can circumvent safely, without really fighting Unity’s design paradigm.
#2 – Don’t put everything in the code
I’ve done a ton of GUI-heavy development, especially in uGUI, and I’ve often run into code where the developer sets up the entire GUI hierarchy in code. There is very little benefit to this approach, as it forces changes to that GUI to be made by a developer in a text editor.
I find this one particularly strange, as developers, with pitchforks in hand, demanded for years that Unity deliver on its promise to provide a fully-featured WYSIWYG GUI system. Unity finally delivered a great system, and some developers continue to develop in a quasi-IMGUI frame of mind.
In fewer words: Use the damn editor. It’s not 1999.
#3 – Don’t miss the forest for the leaves
Yes, I know the saying goes “don’t miss the forest for the trees”, but perhaps unlike most other fields, developers can some times get an extreme case of tunnel vision, and focus on the minutiae, whilst completely ignoring the big picture. Things like naming conventions, bracket placements, prefixes, commenting, etc. Yes, these are important things. Settle on them early (or adapt to them if they are already in place) and quickly, and move on.
Unless you’re under specific constraints, or shooting for a specific target, you don’t have to worry all that much about whether or not a foreach loop is going to beat out a for loop when you’re iterating through a dozen items. The program will have to run a million times before the benefit is seen vs the time you wasted thinking about it or giving other developers shit about it.
Yes, be mindful of best practices when coding, but when wading through the grey area, again, pick a standard, and move on.
#4 – Do consider the business needs
Whether you work for yourself, a start-up, or a big company, remember that the code is the means to an end. When I say business, I don’t necessarily mean the financial part of the equation. I mean, what is the purpose of the program or game you are writing? Believe me, I struggle with this one quite a bit myself, so I have to constantly remind myself that ultimately, the code I’m writing needs to serve the needs of the business first and foremost.
Don’t confuse this with cutting corners to meet deadlines or letting the business drive the implementation details. As a developer, the business will rely on your expertise for executing, and while you should voice your opinions as needed, don’t embark on quixotic quests that take away focus from the primary goal you’re after.
#5 – Don’t write it all on your own
This one ties in a bit to #4. You may be able to write an incredible texture packing solution to end all texture packing solutions, but is that the business you’re in? If you’re developing a social media app, for example, is this really valuable technology to the goals of the company? Furthermore, is the QA and maintenance cost for this feature really something that will benefit the company? Probably not.
Often times, you should turn to off-the-shelf solutions, and let others handle the QA and maintenance of features that are not a core part of your application. Yes, everyone knows you’re the shit and you could write a better one of you wanted to (I’m rolling my eyes), but you’re not doing the project any favors by re-inventing the wheel.
Look for open source, or at the very least, a project that accepts pull requests, if you’re truly concerned with what’s in the code.
#6 – Do make every line count
I recently did a retrospective on a project I’ve been working on. The total code base is in the 400k loc range. An impressive number, but not for the reason some might expect. Whereas some developers might pat themselves on the back for writing so much code, my immediate reaction was one of trying to figure out how to cut that number down drastically. Unless you get paid by the line (in some countries that actually is a thing), there really is nothing impressive about writing a ton of code.
As developers, we should appreciate and strive for simplicity, maintainability, and stability, in order of importance. Simplicity means developers of all skill levels can maintain the code effectively, maintainability means being able to address more bugs, more easily, and the combination of these things leads to stability.
Of course, this doesn’t mean you should artificially attempt to cut down on lines of code for the sake of it. Sometimes, being explicit is more simple, than obfuscating the meaning of something to cut on code written. Find the sweet spot for your project. Do the most, with the least, and re-use as much code as you can. Being on top of your OOP practices is crucial.
#7 – Get some damn rest, you zombies!
Now, I understand that in some cases, management won’t understand this concept, but when you have the choice, try to avoid overtime for prolonged periods of time. A tired developer WILL make more mistakes. Often times they are simple, silly mistakes that are compounded by being tired and less effective at bug-hunting. The issue becomes even greater when you have multiple tired developers working on the same code. You ultimately end up with a clusterfuck of bad code. I have no studies on this, just my personal anecdotal experience, but I’ve found that every hour you spend programming past your limit can easily result in several hours tacked on at the other end of the project in bug fixes and re-writes.
Unfortunately, we do live in the real world, and deadlines are a thing. However, proper planning, pacing, and up-front design can help mitigate delays in a project, reducing the need for overtime or delays.
Wrapping up
As I mentioned in the intro–these are based on my own experience. I hope some of these will help you guys out there. I’d love to hear your thoughts too!
-R
