In this article I discuss my choice of coding style and also touch on functional programming. It’s something I’ve been studying for a while and I’m slowly trying to introduce into my work. Both these things will affect the style of code I post on this blog.
Over the years I’ve learnt that being consistent is more important than being right. As you probably know, when it comes to code style there is no real right anyway. However, I find it best to follow whatever style is used in the codebase you’re working on.
Of course, when working on your own projects you have a bit more freedom. Even better, there are lots of pre-rolled options out there so you don’t have to build your own. When choosing one, I find it useful to stick with the presets rather than try to customise things too much. That way if your team becomes more than one you’ve got a standard style guide to reference.
- 2 space indent
- Single quotes
- No semicolons (The linter will let you know where they are needed)
- Always use === (if you’re not you should read up on this)
- Catches unused variables (very useful)
- And tons more…
As a Ruby developer the first 3 points here fit naturally. For the semicolon lovers, you should really know where and why they are needed. I find putting them everywhere for the sake of it somewhat sloppy.
Why functional programming for games, you ask? Here are a few reasons:
- to write code with as few bugs as possible
- to add code incrementally without fear of regression
- to code as efficiently as possible
- to assert an output for a given input making testing a breeze
- to use all the cool new ES6 features
In order to interface with the Object Oriented BabylonJS library and to take a pragmatic approach to FP, I’m adopting Functional Core, Imperative Shell.
Point-free style (or more formally, tacit programming)
One term that stopped me in my tracks was point-free style. I’ve seen this term used before but never quite understood it. So, this time I decided to do some digging and try to put it into my own words to makes some sense of it:
In mathematics, points are the named parameters in an expression. Point-free style, then, removes the explicit use of these parameters, or points.
We’ll use functional programming and point-free style to solve a common problem. We have an array of strings that need to be converted to numbers.
I’d normally write that like this:
Pretty concise, however the
parseInt(n) is the point we want to remove. So, I thought, why not just pass the
parseInt function straight to
Although this is now point-free,
map passes an index as the second argument to
parseInt which is the radix parameter.
To fix this we can create a little helper function.
This function takes a function as it’s parameter and returns another function that calls our passed in function parameter with the single argument.
If ES6 arrow functions are not your thing:
Now we can do the following:
No more points! The only parameters here are functions.
More comprehensive versions of the
unary function we defined here can be found in functional libraries such as Ramda.
There are a lot of functional programming techniques used here. Passing in
parseInt as a parameter is called higher-order functions; the use of
map instead of a for-loop is called declarative programming; and
parseInt is now point-free.
I’ll probably post more on FP in the future which I hope will help me better understand and solidify the concepts. In future posts I hope to apply FP to game programming problems.
comments powered by Disqus