Codestyle & Methodology

This Antegods development update, written by our programming lead Niels, is a reply to the very informative posts by Joost at Ronimo and talks us through the philosophy about writing code for Antegods and some of the rules that apply to our methodology.

Inspired by two great blogposts by Joost van Dongen, lead programmer and co-founder of Ronimo, I thought it might be interesting to share the Antegods (and Codeglue) code style and methodology. I’ve been working here at Codeglue for 5+ years, but before that I worked at various other companies and one of them was actually Ronimo!

I’ve learned under the strict, but fair hand of Joost and he convinced me of their style and methodology. Working at other companies has taught me other methodologies and what you are about to see will look very similar to what Ronimo uses but with some subtle changes. I’ll try to write a summary of our methods and styles and compare it to Ronimo’s.

Style

I would describe our coding style as a “modern C#” style.

We use plenty of whitespace to keep our code readable (for dyslexic people it’s easier to read code that is not jumbled together).
We don’t have FULL_CAPS for defines or enums but a more ‘refined’ CamelCase
We rarely use comments
We seek clarity above brevity
We use rigid structure in regards to where you declare a variable vs a method

You can download the document [here]

As you can see, it’s very similar to Ronimo’s document, this is because I asked Joost for their style guide as a base when we started working on an official Codeglue coding style :). We have some differences here and there, but in general we are using a style similar to Ronimo.

We prefer to use the American spelling over the British, we are less strict about the order of includes and we have small difference with our enums and switch cases.Spelling is a personal choice, and while the order of includes is important it never was an issue that popped up in our projects. In regards to the enum declaration, the syntax is slightly different, but in our eyes provides much more readability in code:

Here it is clear that Car is an enum, while the assignment is the same. As always I think style options are very personal, and there is no inherently good or bad way to style 🙂

Most programmers have their own coding style, specifically related to whitespace and tabs vs spaces, and it can be easy to deviate from the company style once in awhile.

This is specifically an issue with larger teams, so when working on Terraria we decided to use a Visual Studio plugin to force a certain code format, which worked really well for us. That same method is now used for Antegods and our updated internal engine. The plugin is called AStyle and how we set it up can be found [here].

As you can see it forces the curly braces to be on their own line, besides that, it does indentation and padding, which you can look up here: http://astyle.sourceforge.net/astyle.html

Here is our astyle formatting options:

style=allman

mode=c

indent=tab

indent-preproc-block

indent-preproc-define

indent-col1-comments

pad-oper

pad-comma

pad-header

unpad-paren

align-pointer=type

break-closing-braces

break-one-line-headers

add-braces

close-templates

remove-comment-prefix

break-blocks

min-conditional-indent=0

max-continuation-indent=40

Methodology
We share a lot of our methodology with Ronimo such as

Never continue working on something or step to the next feature when you encountered a crash or a bug. Always fix the crash first.
Don’t optimize your code, always write it for readability. When the game is to slow, profiling will be done to find out where it is slow.
Do not worry about making your code future complete, whenever a new feature needs to be added, the class can be refactored. If it’s very easy to do, than by all means do it.

However we also strongly believe in the “Don’t Repeat Yourself” mantra. There is a good wiki entry: https://en.wikipedia.org/wiki/Don%27t_repeat_yourself and c2 has even more reading material: http://wiki.c2.com/?DontRepeatYourself

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

If you follow this, your code automatically becomes a lot better, as you now automatically create the correct architecture and logic connections.

Code must be readable, not fast! This is often the complete opposite of what students learn at school, but you’ll spend countless hours looking at code, and in most cases a simple for loop does not benefit from a ++i instead of an i++.

Never Guess! If some piece of code is determined to be too slow, by the use of a profiler, then the code will be optimized. The code will then be optimized.

Leave the future in the future; programming for future results is not always the right choice, it leads you astray and easily towards over-engineering your program. We strongly believe in code reviews and going back to refactor code, enhancing or even removing code that does not do its job anymore.

Important

The very first rule in the document; For every rule there is an exception! But I say to that; do not give in easily 🙂

I am sure there are a lot of people that are disagreeing with us on our code style and way of programming, so hop on our discord to chat with us about it!

discord.codeglue.com

I wonder how you approach this subject.

To follow our development updates, please check us out on Tumblr, Twitter or Facebook. And don’t forget to subscribe to our newsletter for info on events and sales.

Antegods is supported by the Dutch Cultural Media Fund, Cultural Industries Fund NL and the MEDIA Programme of the European Union.