Porting as an exercise in code cleanliness.

Porting code from one platform to another brings a whole set of interesting challenges. These challenges bring a whole set of opportunities for looking at your code with fresh eyes.

The biggest challenge is most likely if you need to convert your code into a different programming language. This is an excellent opportunity to again think in higher level concepts rather than getting caught up in syntax.

Most likely that is something which you won't do very frequently over the life of a codebase provided that you made a fairly good language choice to begin with and you are not in a very unique space such as mobile where you generally only have one language choice per platform.

The far more common case is taking the same codebase on Windows or OS X and porting it to the other. In most cases you can actually get the exactly same codebase to compile and run on both platforms with some work and maybe only a few minor sections that are platform-specific.

This is generally a really good opportunity to go back over your code and fix things. Getting rid of things that are maybe ok with one compiler on one platform, but which another complains about. It also gives you the chance to really look at every part of your code, which is the perfect opportunity to also clear it up.

I remember when we ported Snowflake to OS X back in the day. We had a ton of stuff that, while not strictly "wrong", reeked of built on a deadline in 2009 and then never refactored. As such the OS X port was actually really great for cleaning up the code in a ton of places. That port, and the pickiness of GCC as opposed to MSVC, has helped the code quality a lot over the years in the Windows version as well.

Essentially it meant that we had to go back and clean up all the "shortcuts" that MSVC let us take. While this doesn't really make much noticeable difference in the final product on its own it has really made the codebase easier to understand and much quicker to work with and now it kind of works as an additional layer of static checking when new things are implemented.

The port to Linux was also quite interesting in its own way as, due to the the differences in the OS OpenGL, socket, filesystem etc headers from both Windows and OS X we really had to take a look at what we include where as it ended up being quite crucial to not having conflicts on Linux. This really ended up speeding up compilation of Snowflake and brought compile times down to two thirds of what they were previously on Windows as well.

Porting to Linux also brought another interesting thing: needing to run on a system with a case sensitive filesystem. This may not sound like a big thing at first, and it really shouldn't be for all things, but for us what it meant was that we really had to think about content filenames and how we handled those, so it ended up forcing us to set up our own internal rules for how files should be named.

So even if it wasn't for that you end up with a new thing that has value on its own, which is your application running on a new platform, porting code has a bunch of built-in advantages even for the original platform.

So, besides from that you cover a wider potential audience you also have even more potential to produce good code... Sounds like a Win-Win to me.