Generic Coding Tips

Generic Coding Tips

>> Know the intent of your code. What is the purpose of your code? What should the inputs be? What should it output? It can be useful (especially for larger projects) to write out a flow chart that maps how information moves from task to task through the program.

>> Divide your code into sections that fulfill specific tasks, then chain them together. Sometimes it’s worth devoting a code section to its own file to be used by multiple programs rather than coding multiple instances of the same thing into each program. Consider what tasks might be useful for future programs.

>> Create a main project folder and don’t be afraid to use subfolders. Folder hierarchies are your friend when it comes to juggling multiple files in an easy-to-understand manner.

>> Consider having a “resources” subfolder, with pdfs, webpages, etc. of information relevant to your project. For example, I’m currently working on a program to calculate relic densities, so my project folder has a resource subfolder with research papers about relic densities. 

>> Comment your code! Seriously, future you will appreciate it. (I usually also keep a README.txt file in the same folder which describes how to implement the code.)  In the same vein, explicitly state any conventions you’re using and where you’re getting any data you import.

>> Test each section as you build it. Throw in sample values (preferably where you know what the output should be) periodically and make sure it’s doing what you want it to do!

>> SAVE WORKING VERSIONS OF YOUR CODE. Do you have a working build? Save it, then–before augmenting anything–create a new file and work on the next version of the code there. I do this usually via “save” and then “save as”.  Version control is to coding as save points are to video games.

>> Generating a lot of data? Consider saving a sample instance of that data in a subfolder. It can be a massive pain to troubleshoot portions of your program if you have to wait to generate hundreds of data points every time you run it. 

>> Getting an unknown error in a massive amount of code? Isolate the section of code containing the error(s), then create a minimal working example of the section, and keep adding to that example until you either figure out 1. why your original code failed, or 2. until you’ve constructed a new functioning code.