User Tools

Site Tools


analysis:nsb2014:week0

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
analysis:nsb2014:week0 [2014/07/20 10:05]
mvdm [3. Good programming practice]
analysis:nsb2014:week0 [2018/07/07 10:19] (current)
Line 86: Line 86:
  
   * //​Don'​t repeat yourself//. Implementing each piece of functionality only once means your code will be easier to troubleshoot,​ re-use, and extend -- as well as easier to read.   * //​Don'​t repeat yourself//. Implementing each piece of functionality only once means your code will be easier to troubleshoot,​ re-use, and extend -- as well as easier to read.
 +  * //Unit testing//. Provide test scenarios with key pieces of code where you know what the expected outcome is. For data analysis this commonly involves generating artificial data such as white noise or Poisson spike trains of a certain average firing rate. These tests will be extremely helpful in interpreting your data later, and to check if changes you make to the code have not broken its functionality.
   * //​Readability//​. Generally, whatever analysis you are doing, you will probably have to do again. Maybe on the same data after you make a change to the code, maybe after you collect more data. Maybe tomorrow, maybe next year. It is tempting to assume you will remember what you did and why, but this will not always be the case! Plus, even if //you// do, it's likely someone else (such as your adviser, or a collaborator) will have to run and understand your code. Whether or not they can will reflect on you.    * //​Readability//​. Generally, whatever analysis you are doing, you will probably have to do again. Maybe on the same data after you make a change to the code, maybe after you collect more data. Maybe tomorrow, maybe next year. It is tempting to assume you will remember what you did and why, but this will not always be the case! Plus, even if //you// do, it's likely someone else (such as your adviser, or a collaborator) will have to run and understand your code. Whether or not they can will reflect on you. 
   * //​Consistency//​. Use consistent naming schemes for different kinds of variables and functions; always place constants and parameters at the start of each file.   * //​Consistency//​. Use consistent naming schemes for different kinds of variables and functions; always place constants and parameters at the start of each file.
analysis/nsb2014/week0.1405865149.txt.gz ยท Last modified: 2018/07/07 10:19 (external edit)