Coding Conventions

Hey iDevBlogADay,

todays post shifts focus a little bit away from graphics to a more fundamental issue when programming in a team. At Limbic, we’ve recently started a new project, and I love that. Starting with a clean slate, looking back at previous projects, what was good, what was not so good, and trying to do better. This made me reflect a little bit about coding conventions. Let me present you what I’ve come up with.

Coding Conventions

Coding conventions are a very difficult topic. Many religious wars have been fought about this. Everyone that writes code has an opinion on this, and many think their solution is the best. But I think they are completely missing the point. The goal of coding conventions is not to win a beauty contest (which would be very subjective anyways), but to make it easy for others to understand your code, and to add more code that fits in well.

A classical example for coding conventions is the indent styles. A good programmer will have found his specific indent style at which he can work effectively. But a great programmer can work at any given style, and make his code match the surrounding code. As such, it doesn’t really matter what style is chosen. It is more important that everyone sticks to it.

The necessity for a shared coding convention is most obvious when you look at a commit log, and you can see that every single line of a file you’ve edited has been re-indented, brackets moved around, variables and functions renamed by someone else. And when you open it in your editor, half of the text is indented differently than the rest. Because of this you can’t figure out what your own code was originally intended to do, even though you wrote it. There is a good chance you have seen this happening to you. And the other programmer didn’t even mean to offend you, he just wanted to “improve the code” and didn’t know any better.

So far, so good, but which seat should I take style should be used?

Ask 100 programmers, and you’ll get 100 different answers. And each will tell you that his is the one and only style. And that’s the problem: the one and only style simply does not exist, and everyone learned programming in a different way, hence habits differ. Obviously, when you start a new codebase, you want to chose one style, because otherwise everyone will write whatever he or she likes, and it will be chaos.

You’ll probably have that programmer on the team who will be like “oh, it’s easy, just use my style!”. The problem with that usually is that he never documented that style, and he would probably describe a lot of rules with words like “obviously” and “trivial”, instead of properly defining them.

And that’s why I think the best solution to this is to just go out and pick one of the existing popular coding conventions, and stick to it precisely. At Limbic, we decided to use the Google C++ Style Guide (it comes with cpplint, a great script to check for a number of convention violations). Even though a lot of aspects were unintuitive to me at first, I accepted this style and worked with it. And now I love it, it definitely helped me become a better programmer. And I also learned this and that about C++.

Using a popular convention helps when bringing in new coders, too. It’s easier to tell a new programmer “check out the Google Conventions” than to tell him “just look at the rest of the code and do it the same way”, especially if they are somewhat esoteric (I’m pretty sure everyone has seen his share of esoteric code). In case of doubt about a certain style, there is always a place to go back to and look up how it was meant to be (and why).

Finally, keep in mind that the conventions are obviously not set in stone. If a programmer feels that a certain rule is odd, I’d suggest to go and try it anyways. Usually, it’s not as bad as it may sound initially. And more often than not, it has some great advantages that you didn’t think of initially. If that doesn’t work, you can still change the rules, by writing up some extensions.

Why are you telling me all this?

That’s a fair question. And I guess the point to take way is as simple as this: I learned that using tolerance when it comes to coding conventions is a huge gain, and fighting for your own style is a huge pain. The art in programming (in a team) is not to write fancy code, but rather to build solid code that is easy to maintain and extend. And that’s a lot easier if everyone pulls in the same direction.

HDR Rendering on iOS (iPad2/iPhone 4S)

Hey iDevBlogADay,

I’m excited for todays post, because this has been sitting on my desk for a while. With the public release of iOS 5.0, I can finally release this stuff. I’m talking about a little HDR tech demo that I wrote during the iOS 5.0 beta to figure out how, and how well, HDR rendering works with the new A5 only OpenGL ES 2.0 extensions, specifically GL_OES_texture_float, GL_OES_texture_half_float, GL_OES_texture_half_float_linear, and GL_EXT_color_buffer_half_float. I’ve made the tech demo public on github. I wont go into all the details (you can see the details on github), but rather focus on the issues I had creating the demo and working with those extensions. I’m not really going to talk about what HDR is or what benefits are gained from HDR, but focus on the particular details for implementing an HDR render on iOS.

Continue reading

Writing Maya Plugins

Hey iDevBlogADay,

A while ago we at Limbic decided we need a tighter integration with the content creation tools and the artists. Before, we had stand-alone scripts and programs that would convert common format like .obj into an engine format. However, this doesn’t work very well when the rendering gets more complex, like adding skinning, forward kinematic animations, multiple texture sets, etc. The choices were to look at Maya or 3dsmax, but since 3dsmax is only available on Windows, we decided to go with Maya.

So we started to learn Maya, build up knowledge about the APIs and the setting up a work environment. This turned out to take way longer than expected, as Maya is a quite powerful but somewhat chaotic application. To ease the pain for others, I’d like to post about some of my findings now and then. Todays post will be about the different ways to write a plugin.

Continue reading

Debugging Cocoa

Hey iDevBlogADay,

we recently had an issue in Cocoa, where for some reason we had two view controllers active at the same time (with two OpenGLES views active), leading to a bunch of issues. I then realized that there seem to be no good Cocoa debugging tools. From my Win32 days, I remember that little tool Spy++, which could inspect the window hierarchy. That was a great to help ensure everything is sane. I think with a tool like this many bugs in our Cocoa apps could’ve been avoided or more easily spotted. Continue reading