Background
The GitHub workflow and code reviewing is becoming a common culture nowadays. One of the drawbacks of this culture is that you're not sure if you should comment on minor coding style mistakes, like whether you should add a space after a comma, or if you should add a newline where you have many arguments. It's really frustrating for both the reviewer and the reviewee to have to see those kind of comments, even though following the coding style is an important issue for maintaining software.
Then we found HoundCI. HoundCI automatically comments on coding style violations on GitHub whenever a pull request is opened.
At Akatsuki we write server-side software in Ruby, and client-side software in C++. Since we started using HoundCI on the server-side a few months ago, the number of coding style violations reduced dramatically. Seeing that change, I started to think it'll be great if we could have HoundCI on the client-side as well.
However, there was a problem -- HoundCI only supported JavaScript, CoffeeScript and Ruby as of Oct. 2014. But HoundCI was open source, so we decided to make a fork and add support to C++. That's what I want to introduce in this article -- adding C++ support to HoundCI.
Modification
At first, I thought adding support to a new language would take some time. But as HoundCI was well-designed and well-coded, it wasn't much trouble (within a day!). After all, it's only a Mashup of HoundCI and CPPLINT, replacing rubocop for Ruby to CPPLINT for C++. That's what's so great about open source. If you want a new feature, you can make it yourself!
github.com/sergeant-wizard/hound/compare/cpplint
With the standard service you can't use a forked version of HoundCI, so we run HoundCI on a private server with AWS.
With Ruby, you can change the settings among different repositories by placing a .hound.yml -- our CPPLINT version has yet to support that feature.
Some more automation
Applying HoundCI + CPPLINT to a project that's been running for a few months by engineers not really interested in following the coding style rules was... disastrous, as you can imagine, with as many as 100 violation warnings in a single pull request. So we decided to automate the fixing process as well using git-filter. The following scripts really helped decrease the ammount of coding style violations.
[gist id=c4ebd58194bcc7fd804c]
The drawback is that you have to be careful not to change the logic of the program if you're going to apply this kind of script to a project that's already under operation.
Client-side code doesn't have to suck
I hear that until recently, client-side programmers in the game industry didn't care much about code readability and maintainability, because you didn't have to work on the code after the game had been released. But that rule doesn't apply anymore, especially to mobile-phone games, where it is not rare to have multiple client version updates within a month. With such short-span releases, I think it's essential to adopt the techniques and culture of Continuous Integration to the client-side as well. So that's what we're aiming at here in Akatsuki, and I wanted to introduce some of the technical elements we've been using.
Disclaimer
Mr. Scott Albertson from HoundCI has granted permission to post this article.
