Programming for Scientists

Links to some great articles on programming

Photo by Manel

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.

Holding a program in one’s head by Paul Graham. An article about the psychological side of programming: avoid distractions, work in long stretches, etc. This article, I believe, will make more sense to the scientist-programmer than other programmers because, as a scientist, you are more used to holding a problem space in your head and trying to manipulate it to find a solution(s). The points in this article, when taken to heart, will improve the quality of your coding in a way that is completely different from purely technical improvements.

I hope you enjoy these posts and articles, they all shed light onto different areas of the craft we call programming. Please share your interesting links in the comments.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.