Links to some great articles on programming

The internet is full of smart people writing intelligently on how to write good software. Very few of these articles are from the perspective of a scientist (hence this blog!) but a lot of what they write is useful, interesting and, occasionally, entertaining. This post is of some of the best articles, posts and websites that have taught us what we know today.


Six ways to write more comprehensible code, by Jeff Vogel uses a game called ‘Kill Bad Aliens’ as a setting for his examples on writing better code. The code is C++ but the tips are nearly all applicable to any language. The only one I don’t agree with is number 2: ‘Use #define a lot. No, a LOT.’ #defines are part of the C/C++ pre-processor macro language that replaces one string with another before the compiler is run. It allows the programmer to replace ‘magic numbers‘ with more descriptive tokens without the overhead of creating constants. I agree that #defines are better than magic numbers but I believe most of those values should be loaded as data and not hard-coded into your program. This way, when (and it will be when and not if) you change your mind you only need to change the data files and not recompile your code. For something that needs as much tuning as a game having loaded, not compiled, data is very important as it allows quicker iterations which means more iterations in a given time and therefore more chance to get the best possible experience.

Bad names. Eric Lippert is one of the people who design the C# language at Microsoft. His blog can be deeply technical but it is always an interesting read. In this post he talks about bad variable/function/class names he has encountered in the C# compiler and what problems various names expose. For instance any name with ‘Misc’ in it is doing more than one thing which is ‘a bad thingTM’. The comments have a few more chipped in by the peanut gallery.

Is it worth spending time on design? by Martin Fowler (the real name is DesignStaminaHypothesis but that name is a bit opaque). This post is about the hypothesis that there is a point below which spending time on design will actually slow you down but that this point is very difficult to judge and, in the authors opinion, is lower than people think. I like this post because it shows that very few things are set in stone and it references two related points (links are in the article): 1) Productivity of a programmer is very hard to measure and 2) the author introduces the concept of technical debt to describe the cost to a project of not planning. Technical Debt is a very powerful concept and can be applied to any time you cut corners to get something done sooners than if you had done it properly.