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.
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
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!
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.
Categories
Submit a Comment