[/caption]The purpose of this blog is to help scientists program more effectively and efficiently, so they can get more science done. For those of you who'd like to be systematic in your learning, we present the prog4sci software project primer!
Choosing a programming language
If you haven't already done so, you'll need to choose a language in which to program for this project. Here are some articles on how to do just that (part one and part two). It can also be useful to see some Examples of how to choose a programming language, and a useful reference is a big list of programming languages.
Planning
The first thing you need to do when planning your projects is to decide on what are the objectives of your project. Once you've done that, you can start planning the architecture of your code. This is where the basics of pseudocode will come in handy.
Prototyping
You may decide that you should be prototyping your code. This can be an important step in learning at least one good way of addressing your objectives.
Coding
As you might expect, we've written a few articles on coding :-) Coding is a craft, so you might want to spend some time contemplating the craft of coding. You should also start to learn some principles of good codingmore principles of good coding). Some examples of good coding vs bad coding will also be useful, as well as a coding case study. And as a philosophy and approach to writing the code itself, we heartily recommend the joys of literate programming. (and then some
And you might also want to consider using some source control.
Testing and debugging
If you don't test your code, how do you know that it actually works? You don't. Testing is very, very important and there are some particular considerations for testing and the Scientist-Programmer. This is especially true if your code does a lot of number-crunching (testing your number-crunching code).
Finding bugs requires debugging, which is very different to writing code. In particular, it's helpful to understand the psychology of debugging and to know the key questions to ask when debugging. You may also find it helpful to read our advice on some ways to find those 'invisible' bugs.
Optimisation
You may not need to optimise, but if you do then do it right! Read our introduction to code optimisation, as well as a second article on how to optimise your code. And remember that one way to optimise is to use a faster computer. Or multiple computers, in which case you'll need to know about parallel processing.
Finishing...
Have you finished your project yet? How do you decide. There are the four levels of making code work to consider, as well as thinking about the concept of code that's good enough.
Maintenance
maintenance may not be glamorous, but it's important nevertheless. So don't skimp on it. And beware of feature creep in scientific code.
What next?
Now you really have finished, it might be advantageous to review how the project went (and also see another review article here).
In conclusion...
As Scientist-Programmers, we are in the business of building scientific tools that are actually useful. This article gives a primer of the different basic elements that go into doing just that. Enjoy!
No comments:
Post a Comment