I have been using Igor Pro for the last 4 years now.
Here are some tips I wish I would have known when I started so I would be more organized:
1. Folders and sub folders. Number 1 tip because it makes finding your data much more manageable than keeping everything in root:
2. When starting out coding, write out exactly what each line of code does.
3. I recently have started using separate procedure files. It helps when using Github and tracking changes.
4. Keep names simple and specific. Get into the habit of using conventions.
That's all I could think of off the top of my head.
As you can see from the comments, the question is rather vague and can be interpreted in many ways. However, I feel like most of my time coding is spent optimizing and organizing ("premature optimization is the root of all evil"- Donald Knuth), so I am interested to to see other people's responses for staying organized.
Some general recommendations that work well for me:
- ALWAYS use the data browser; by default it doesn't open on first start-up
- already mentioned but use datafolders
- avoid liberal (wave) names, i.e. use T_K instead of 'T(K)'
- think about organising data in multidimensional instead of 1D waves to avoid clutter
- think about using an additional layer to store uncertainties of data which are organised in a matrix (see point above). That way you can store (and save) very large data sets in a single wave.
- make use of dimension labels for annotation instead of text waves
I'd like to add
* Avoid over-structuring
* Use SI base units for waves and variables
* Documentation, documentation, documentation
HJ
I must add a strong agreement for the 3rd point. One thought is to create two separate versions of a "package" (an Igor Pro experiment). In one, use Notebooks to log records of what and why you are doing what you do. Strip out the notebooks for the release version. Alternatively or especially in addition to this, learn how to create Help files for your package code.
As an aside, I've been looking for alternatives to code + document in one app. Options such as Quiver (Mac) (http://happenapps.com) come to mind. You could go down this road as well depending on your desire/need/ambition level.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
There have been some great tips in this thread that I agree with. Further good advice I've picked up from IgorExchange has been:
1. To write code to make analysis clean and reproducible. Discussion is here http://www.igorexchange.com/node/6888
Before this, I used an Igor Experiment as a place to build an analysis, loading stuff in, running some code, fiddling more etc. Now an Experiment file is not so precious, it is just a shell to run some code on some external data. Having everything programmed to run on the current dataset, but also any future dataset is much better. Similar to rmd/knitting in Rstudio if people are familiar with that.
2. Thomas Braun's coding conventions http://www.igorexchange.com/project/CodingConventions have been a very useful guide to best practice.
3. I use atom.io with the Igor Pro syntax for offline code editing.
I'd be interested to know how other people have integrated git into their Igor Pro programming workflow. I use ipfs in User Procedures and copy to a separate directory which is controlled by git and then sync with github. I have a feeling this is sub-optimal and I should probably just version control my code directly in User Procedures. Would like to know how others are doing it.
3. I use atom.io with the Igor Pro syntax for offline code editing.
Are the syntax definitions posted here on igorexchange or are they already integrated upstream?
sjr51 wrote:
I'd be interested to know how other people have integrated git into their Igor Pro programming workflow. I use ipfs in User Procedures and copy to a separate directory which is controlled by git and then sync with github. I have a feeling this is sub-optimal and I should probably just version control my code directly in User Procedures. Would like to know how others are doing it.
I also use git with some repositories being on github. I prefer creating windows-style links from the repositories's procedure folder to User Procedures. In that way I don't have duplicated versions floating around. On the Mac you can create symbolic links instead.
For atom.io,the igor-pro-light-syntax 0.5.0 by jameskli is available as a "community theme" in Settings.
The language settings are a package by shanemcmahon. IIRC, I installed this from his github page https://github.com/shanemcmahon/language-igor
At this point, I might add that one of the new features of Igor 7 is toleration of procedure files (or any plain-text notebook, for that matter) being modified outside of Igor while they are open in Igor.
February 8, 2017 at 04:38 am - Permalink
Back to the topic. Are you talking about organizing code or organizing graphs in Igor?
February 8, 2017 at 07:35 am - Permalink
Here are some tips I wish I would have known when I started so I would be more organized:
1. Folders and sub folders. Number 1 tip because it makes finding your data much more manageable than keeping everything in root:
2. When starting out coding, write out exactly what each line of code does.
3. I recently have started using separate procedure files. It helps when using Github and tracking changes.
4. Keep names simple and specific. Get into the habit of using conventions.
That's all I could think of off the top of my head.
As you can see from the comments, the question is rather vague and can be interpreted in many ways. However, I feel like most of my time coding is spent optimizing and organizing ("premature optimization is the root of all evil"- Donald Knuth), so I am interested to to see other people's responses for staying organized.
Regards,
Austen
February 9, 2017 at 07:50 pm - Permalink
Some general recommendations that work well for me:
- ALWAYS use the data browser; by default it doesn't open on first start-up
- already mentioned but use datafolders
- avoid liberal (wave) names, i.e. use T_K instead of 'T(K)'
- think about organising data in multidimensional instead of 1D waves to avoid clutter
- think about using an additional layer to store uncertainties of data which are organised in a matrix (see point above). That way you can store (and save) very large data sets in a single wave.
- make use of dimension labels for annotation instead of text waves
February 9, 2017 at 11:54 pm - Permalink
* Avoid over-structuring
* Use SI base units for waves and variables
* Documentation, documentation, documentation
HJ
February 10, 2017 at 12:07 am - Permalink
It does in Igor Pro 7, and you can also use Ctrl/Cmd+b to open it.
February 10, 2017 at 07:36 am - Permalink
I must add a strong agreement for the 3rd point. One thought is to create two separate versions of a "package" (an Igor Pro experiment). In one, use Notebooks to log records of what and why you are doing what you do. Strip out the notebooks for the release version. Alternatively or especially in addition to this, learn how to create Help files for your package code.
As an aside, I've been looking for alternatives to code + document in one app. Options such as Quiver (Mac) (http://happenapps.com) come to mind. You could go down this road as well depending on your desire/need/ambition level.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
February 11, 2017 at 07:24 am - Permalink
1. To write code to make analysis clean and reproducible. Discussion is here
http://www.igorexchange.com/node/6888
Before this, I used an Igor Experiment as a place to build an analysis, loading stuff in, running some code, fiddling more etc. Now an Experiment file is not so precious, it is just a shell to run some code on some external data. Having everything programmed to run on the current dataset, but also any future dataset is much better. Similar to rmd/knitting in Rstudio if people are familiar with that.
2. Thomas Braun's coding conventions http://www.igorexchange.com/project/CodingConventions have been a very useful guide to best practice.
3. I use atom.io with the Igor Pro syntax for offline code editing.
I'd be interested to know how other people have integrated git into their Igor Pro programming workflow. I use ipfs in User Procedures and copy to a separate directory which is controlled by git and then sync with github. I have a feeling this is sub-optimal and I should probably just version control my code directly in User Procedures. Would like to know how others are doing it.
February 13, 2017 at 01:34 pm - Permalink
Happy to hear that it is useful!
Are the syntax definitions posted here on igorexchange or are they already integrated upstream?
I also use git with some repositories being on github. I prefer creating windows-style links from the repositories's procedure folder to User Procedures. In that way I don't have duplicated versions floating around. On the Mac you can create symbolic links instead.
February 15, 2017 at 10:21 am - Permalink
For atom.io,the igor-pro-light-syntax 0.5.0 by jameskli is available as a "community theme" in Settings.
The language settings are a package by shanemcmahon. IIRC, I installed this from his github page
https://github.com/shanemcmahon/language-igor
Thanks for the tip re:github I will try that.
February 16, 2017 at 03:10 am - Permalink
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
February 17, 2017 at 12:02 pm - Permalink
I recognize the question was vague, I am quite new at this. Thanks a lot for all the nice ideas.
raphael
June 22, 2017 at 01:00 am - Permalink