Advice on breaking bad programming habits

As a starting point, consider moving the procedure file in a representative experiment to a stand-alone procedure.

• Open an experiment with the most recent or most reliable procedure file.
• Open the main procedure window.
• Choose the menu option File->Save Procedure Copy.
• Save the copy of the procedure in a folder in the User Procedures folder of the WaveMetrics folder. Title the folder with a respectable, short name to represent the theme of the entire procedure. For example, Analysis Tools or Curve Fitting Process or ... Title the procedure with a respectable, short name to represent it, for example also Main Analysis Procedure or equivalent.
• Start a new Igor Pro experiment.
• Open the main procedure window and put the #include "Main Analysis Procedure" statement in the beginning portion of the window.
• Recompile the code.

You should now have the equivalent of access to the procedures without having to duplicate the experiment containing the main procedure.

The next step begins the process for development. At the top portion of the Main Analysis Procedure, include the pragma #version=1.00. Save the experiment that you just opened with a name equivalent to below.

-> Develop Main Analysis v1.00.pxp

You now have an experiment where you devote your efforts solely to developing and improving the procedures for analysis, not to muck about in the code while analyzing data. The work you do on the #include procedure in the Develop experiment transfers to all future experiments that have the #include "Main Analysis Procedure" pragma.

At this point, each time before you open the Develop experiment, decide what target you will resolve. Targets can include such things as ->add a feature, ->fix a bug, ->streamline a certain code segment, or ->remove clutter in something. Also, every time before you open the Develop ... experiment, create a ZIP archive of the main procedure file as a backup. When you reach a desired milestone in development or improvement, increment the version number in the procedure file and save the experiment with the incremented version number. Approaches vary on setting incremental version numbers. I typically increment by steps of 0.10 for bug fixes or new features, and I increment all other work by steps of 0.01.

To summarize, the important points to prevent being overwhelmed are a) extract the cores procedures to a separate procedure file that can be called by #include, b) develop a set of milestones that you attack one at a time, c) hold to a robust approach to capture snapshot backups of the main procedure file before you undertake any revisions on it, and d) maintain a systematic approach to versioning the main procedure file (and development experiment) to mark your success after reaching a milestone.

I hope my suggestions might help you get started on a more structured approach to your coding efforts.

I can give tons of good advice ;)

But I'm also wondering what you think is going wrong with your current approach.

Jeffrey,  thats a good start - many thanks.

Thomas,

the problem for me is one of managing my programming developments which have become unwieldy: for example in 2024 with developments over 50 experiments totally over 13 GB.  Present version is 0.5GB with 20 procedures and hundreds of functions, some used and some defunct.  No control on function versions and modifcations ( only commented changes) .  I am the sole user. 

Keeping tabs on updates to functions is probably the biggest issue.

"...maintain a systematic approach to versioning the main procedure file (and development experiment) to mark your success after reaching a milestone."

Yes, as Jeffrey pointed out versioning is particularly important in this kind of projects.  I remember when I started developing in Igor one of my first projects dealed with processing data files issued by a custom acquisition program originally written by someone else.  As the experiment evolved new informations were added to the files and I was updating the processing routines accordingly. However initially there was no version info in the custom files so that at some point the latest version of my processing software was no longer compatible with older files which posed many problems. Since then when I develop my own aquisition programs  the file format/acquisition software versions are coded within the first lines (or bytes) of the file, my processing software starts reading those bytes and selects the appropriate version of the loader/processing routines.   Now I can semlessly load and process files stored 15 years ago, even when I don't remember which file format version was used at the time.

> Keeping tabs on updates to functions is probably the biggest issue.

As a follow up, you might also want to consider whether you can improve on how you track your modifications. One method is to keep the records of changes in the procedure files themselves. For example, you could include a section near the start of a procedure file that keeps track of every modification that you make on it. Another method is to keep versioning records in a separate document system. Whichever approach you take, be systematic. Note the changes promptly when they are made, categorize the general type of change made (e.g. bug fix, code improvement, UI improvement, new feature, code pruning, ...) in addition to putting at least a brief note about the specific change(s), and date stamp the change record.

A very minor addition to the suggestions given so far is to take advantage of the Code Marker Comments tool in the built in code editor.   It can be accessed by the sort of map marker icon in the upper left of the editor just to the right of the back and forward arrows..

This can be used to jump around to significant locations in your code.  I use it to mark the end of my header comments and the locations of other things such as structure, menu, and constant definitions.

see: 

Thanks All,  just the type of advice i hoped for!

I find that the best motivation for writing cleaner code is to share code with others.

My advice would be to break everything down into as-compact-as-possible procedure files and store these in User Procedures. This really echoes the advice of others, and the wording of your question suggests that that is where you are heading anyway. If, as the sole user, you work always on the same computer, I cannot see any drawback to doing things this way. If you currently move your self-contained pxp files between computers, you will need to think about how to keep the User Procedures folders synchronized, but it's not a very formidable task.

A system that I find helpful is to keep a 'default includes' procedure file in the Igor Procedures folder. This ensures that my personal selection of go-to packages is always loaded. I also use that file to add a handful of useful one-liner menu items that I like to have available, like this:

#pragma version=1.02
 
// Procedure files to load at startup.
// #include "file name" for user procedures,  
// #include <file name> for WaveMetrics procedure files
 
// *** programming & procedure file maintenance ***
#include "UserProcLoader"
 
// and so on, a list of file loaders and other utility functions to be included
 
// *** menu definitions ***
menu "Misc", hideable
    "Prepare project release...", /Q, updater#PrepareProjectRelease()
    "Disable Threadsafe Support", Execute/P/Q "SetIgorOption poundDefine=THREADING_DISABLED"; Execute/P/Q "SetIgorOption DisableThreadsafe=1"
    "Enable Threadsafe Support",  Execute/P/Q "SetIgorOption poundUnDefine=THREADING_DISABLED"; Execute/P/Q "SetIgorOption DisableThreadsafe=0"
end

I strongly recommend sticking with the default User Procedures folder for storing all other procedures.