a practical guide to being less awful at programming� �or: stop! if you commit that you’ll have to live with it!

sorry, and you are?

• Alex Darby
• technical & design director of darbotron ltd
• making videogames professionally since 1996
• 20+ shipped multi-platform console titles
• founding member of FreeStyleGames (DJ Hero)
• co-created & taught a Masters course in game dev
• programmer / designer to at least lead level
• member of BAFTA,

​

• very broad programming experience
• if you need a label, maybe ‘Technical Generalist’?

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

‘how to be less awful’?

• software engineering is a complex topic
• I won’t try to tell you how to succeed
• I wouldn’t trust anyone who says they can!

​

• best we can realistically achieve:
• share our knowledge and experience
• reduce risks by avoiding known mistakes

​

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

prelude: reducing risk

• ultimate goal of all development processes
• risk == time == money

​

• games are complex & change during dev
• conflicting software engineering goals
• enough architecture/structure to afford robustness
• not so much it can’t be changed at the drop of a hat

​

• these are big picture problems!
• they have inspired many books
• not to mention whole production methodologies

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

the medium-sized problem

• I’ve seen a lot of almost-shipped codebases
• very different high level architectures
• most suffering essentially the same problems

​

• the biggest problems usually started small
• benign issues accumulate & reach toxic levels
• a meso level problem (between micro & macro)

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

medium-sized problems

• super important when porting to console
• not just issues of porting engine code
• platform requirements are not negotiable
• many ‘default’ PC code idioms won’t cut it
• “game flow” logic may need to change a lot
• I hope following this philosophy will help

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

how does it happen?

• by accident, mostly

​

• hit driven business model
• more or less constant deadline pressure
• features take priority over technical debt
• large percentage of project specific code

​

• rarely time to stop & think - let alone for CPD
• experience: completed dev cycles vs. time in job

​

​

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

the take-away

• Minimum Viable Software Engineering
• everyday principles to improve code quality
• bear in mind when doing code reviews

​

• effective at the minute-to-minute level
• addressing the medium-sized problem
• proactively reduce risk: avoid cumulative issues

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

the take-away: a caveat

• the actual take-away is the idea of MVSE
• I don’t pretend to have the whole answer
• what I have is a start

​

• please do ask questions
• I’m hoping for a healthy amount of Q&A time

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

guiding principles

• take responsibility
• once you commit you have to live with it
• minimise risk
• ease of understanding
• ease of change
• ease of debugging
• use idioms which statistically reduce bugs
• don’t reduce productivity

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

thought for the day

​

"All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections."

​

David Wheeler (1927-2004)

​

also inventor of the function call (or ‘Wheeler Jump’!)

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

know your enemy!

• most dangerous thing in your codebase?

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

mutability

• mutation is dangerous
• maximise locality of mutability
• ideally only 1 line in your code where any given variable is assigned
• best argument for accessors
• statistically less bugs
• easily traceable access
• I even use them inside their own class

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

state & conditionals

• be explicit about object state
• don’t use bools - use enums
• prefer switch to if
• we’ve all seen a 1000 line if-elseif-else
• dangerous & implicit
• close to worst case for bug fixing
• no-one ever wrote one in one go!
• fix it: if you don’t who will?

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

duplication & abstraction

• try not to write the same line of code twice
• don‘t copy-paste, write a function
• IMO accessors fall under this rule
• CAVEAT: don’t get lost in refactoring / OOP!

​

• abstract anything likely to change
• only needs a thin abstraction
• classic example (C++):
• most libraries / engines etc. wrap allocations
• allocation code can change without affecting client code

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

lifetime, visibility, & scope

• control lifetime explicitly
• managing: initialisation & shutdown ordering
• managing: system resources
• think carefully about visibility & scope
• more visible = more interactions
• higher chance of bugs AND more places to look for causes
• beware lazy initialised globals!
• visible everywhere & no control over scope
• lazily initialised singleton is the most common anti-pattern
• not fundamentally evil but the root of many nasty issues

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

async as standard

• more or less everything is async these days
• this is particularly true of console APIs
• trivial to make an async interface for sync code
• impossible/undesirable the other way around
• your life will be easier if you
• assume all data I/O is async
• make all game state change logic “async aware”
• front end menus are a prime example

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

interface & responsibility

• think about class interfaces
• enum vs bool
• the myth of ‘sensible’ names
• semantic implications of function signatures
• separation of responsibility
• don‘t make a class do >1 thing, make a new class
• if you have to, at least make it easy to refactor out later
• classic model/view/controller is a useful lens

​

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

beware the OOP rabbit hole

• intellectual time sink
• OOP is taught as a front-loaded design process
• tends toward over-engineering & falling foul of assumptions

• abstracting into base classes can be A Very Bad Idea™
• causes dependencies on concrete base class behaviour
• can take ages to make “simple” changes because of the knock-ons

• composition & interfaces is often better
• slightly more typing but less constrained & much more flexible
• interfaces satisfy external collaboration requirements
• this is particularly important & mind-saving for UI work

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

design patterns

• very much worth knowing about
• well understood and named code idioms
• great short-hand for discussing complex ideas
• IMO primarily useful as a grab-bag of tools to borrow from
• potentially part of the OOP rabbit hole
• beware:
• thinking of problems in terms of “what pattern can I use”
• best solutions are often a mix & match of ideas
• the internet’s well intentioned bad implementation choices
• c.f. lazy initialised singleton!!!

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

my approach to writing code

• have a quick think about it
• I usually write an incrementally ordered bullet point plan
• of incremental and testable steps
• consider the existing code the new code will collaborate with
• just get it working
• fail fast - shows up bad assumptions
• don’t be scared to throw away code - you still learn from it
• refactor proactively
• focus on ease of future change e.g.
• uncontrolled scopes to limit visibility of local variables
• avoid using member variables like invisible function params
• iterate until it’s good enough to commit
• accept it will likely be changed later
• use comments to highlight & explain known shortcomings

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

personal responsibility

• refactor now not later
• If a class has > 1 responsibility split it
• track technical debt
• don’t have time to do it properly right this second?
• keep track of known issues
• allocate time to fix them

​

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

self documenting code

• code IS its own best documentation…
• …only if you name everything explicitly & structure it well
• name identifiers & lay it out so code reads like prose
• optimise for ease of understanding
• typing is rarely the bottleneck in programming
• …you still NEED comments
• to explain everything else
• e.g. most maths; context for design decisions, quirks, constraints, dependencies, ordering issues etc.
• take responsibility for fixing it

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

example: porting to consoles

• platform requirements are non negotiable
• may/will require platform specific behaviour
• multiple users & controllers
• async library calls for a lot of things
• specific game-flow behaviours
• correctly reporting errors to the user

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

that sounds like a lot of work!

• … and it totally can be
• but, but, engine X is already on platform Y!
• engines help, but your game must be compliant
• still requires significant effort
• complexity depends a lot on your code
• online MP? >= 2x the porting effort vs. SP
• applying MVSE can help

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

e.g. explicit state

• states to track
• the prime directive: identity
• managing user, controller, & save data
• easy (& optional) on PC – but not on console
• game flow:
• initialisation, reset, update, shutdown
• title screen, front end, loading, gameplay
• ability to navigate game state from code
• e.g. when the active user signs out, or receiving an MP invite

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

e.g. lifetime & async

• system resources are limited on console
• fixed memory size
• managing object / data lifetimes is key
• c.f. explicit state
• almost all I/O needs to be async
• assume async for all IO protects you from this via the magic of abstraction

​

​

​

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

MVSE summary

• MVSE == reduce risk == save time == save money
• Mantra: you commit it, you live with it
• always be explicit
• localise mutability
• minimise duplication
• don‘t put off refactoring
• don’t get stuck in OOP rabbit holes
• assume async for all I/O

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

a final aside…code reviews

• WTF/minute as a quality metric
• read through some code & count the WTFs
• a WTF can be cancelled..
• IFF ‘ah…ok’ is elicited by subsequent understanding
• divide WTFs by time taken in review

​

• try it, it really works*

* and it’s much more productive than arguing about tabs vs spaces

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron

questions etc.

• please ask me questions!

​

• Further reading / stuff I didn’t have time for…
• Semantic wrappers / type-rich code

https://goo.gl/xrxSLa

• OOP vs DOD:

https://www.youtube.com/watch?v=92KFSD3ObrY

• Philosophy of programming

https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey/

• Automated Testing on Live Games

https://www.youtube.com/watch?v=KmaGxprTUfI

​

​

// a practical guide to being less awful at programming

// Alex Darby - @darbotron