Post - 0 What this blog is for
Ask to see a scientist’s code and you'll often get embarrassed looks and many apologies before they’ll show it to you. Scientists get a bad rap for writing bad code and there are several factors that contribute to this. A lot of the code we write is one-time use, so spending time polishing it can feel like a waste of time. The focus is on doing the science and getting the results over the style and how “good” the code is (we’ll get to what that means later).
The majority of computational physics education focuses on numerical techniques rather than coding techniques, and scientists have usually only taken between zero and two computer science classes before writing code for research. The end result of this is cumbersome scientific code (many lines, unclear, hard to read) that is hard to pass from scientist to scientist (how many times have you heard of someone having to rewrite code from scratch after a grad student/postdoc leaves?) and may have bugs ranging from benign to scientifically significant.
The purpose of this blog is to show you a better way to write scientific code by focusing on three topics: Code Reuse and Readability, Design Documents, and Testing.
Focusing on Code Reuse and Readability when programming makes it much easier to organize your code, allows for less places for bugs to hide, and makes it easier to make changes so that you can run new simulated experiments faster.
Writing a Design Document for your projects lays out a clear chain of logic from Interesting Physics to Real Live Code. It also provides a handy reference as you write the code as well as for when someone else (or you two weeks after you wrote it) needs to read it.
Testing locks down key behavior you want in your simulation and provides confidence that the behavior of your simulation is not a subtle bug masquerading as a result.
This aims to be a weekly blog - updating on Fridays - covering Code Reuse and Readability, Design Documents, and Testing in-depth and in the context of computational physics.