Managing large programs

Code tips and tricks for beginners
Post Reply
f1test
Posts: 15
Joined: Tue Nov 29, 2022 3:13 pm
Has thanked: 2 times
Been thanked: 11 times

Managing large programs

Post by f1test »

Hi
I wrote a program for 8266, it has hundreds of lines. I would like to improve it for ESP 32.
Is there any method for efficient management of large programs?
It is difficult to navigate through the code if it is in a single tab. Multiple tabs, file inclusion. Some suggestions would be nice.
User avatar
cicciocb
Site Admin
Posts: 1889
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 405 times
Been thanked: 1261 times
Contact:

Re: Managing large programs

Post by cicciocb »

Hi f1test,
welcome to the forum.
In the current version it is not possible to import external libraries so all the code must be in a single .bas file.
This is something that might be included in the future
User avatar
Electroguard
Posts: 835
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 267 times
Been thanked: 317 times

Re: Managing large programs

Post by Electroguard »

Hi, my head space cannot cope with hundreds (sometimes over a thousand) lines, so I use some techniques to help a bit.

tabs2.jpg

If the devices are connected via router with different IP addresses, several devices can be connected at the same time, so several different Editor pages open in browser tabs, some looking at copies of the same script.
This allows editing code on a device, while having other editor windows open on other devices showing relevant areas of the same code for reference and copying and pasting from.
Instead of tabs you could have two different device Editors showing the same script in different browser windows side by side, for quick comparison.
I use a different browser for connecting to my annex devices than for internet access.


Over time I have developed a script methodology which helps me to cope a bit better.
I declare all variables at the top of the script before the WAIT (for interrupt events), so I know where to find them and their default values.
I tend not to use unnecessary spaces, eliminating as much unwanted white space as possible, eg: a=a+1 rather than a = a + 1.
This makes it easier to notice deliberately inserted white space in a big mass of code.
When editing a line of code deep in the script that I may need to come back to, I often insert blanks lines before and after it, and insert blank spaces before and after the edit.
This makes it stick out from the rest, and therefore easier to find when scrolling through later.

I leave 2 blank lines after the WAIT, followed by whatever is the latest subroutine I am working on.
When starting another new subroutine it pushes the previous down deeper ... but they are still in ascending order of most recent for quick reference.
I leave 1 blank line between subroutines, but no blank lines inside subroutines, except where I deliberately insert a few blank lines as white space above and below whatever I'm currently working on - it's easier for my brain to pick out white space from a mass of content, making it easier to quickly return to.

Any subroutines I'm not working on but may need to refer to, I put down at the bottom of the script, where I can quickly reach whenever needed.
Unless it is a complicated existing old subroutines which I have decided to redo again from scratch, in which case I keep the renamed old subroutine (which is no longer referenced by the script) underneath its new replacement - not just for referring to, but in case I may need to rename it to reuse it again for some reason. No need to delete the old renamed subroutine until I am confident I will no longer need.

Any subroutines that are finished and not expected to be referred to, I can bury in the middle of the script and forget about them.

I plainly mark the last line of the script to make it obvious if the script has somehow become truncated and corrupted
'--------- END --------

After the END line I sometimes put other code not referenced in the script but which I may need to refer to, which I will delete when done.
This might be commented out code from other scripts, or commented notes such as a list of all the scripts subroutine names or other reminders.


Good luck.
You do not have the required permissions to view the files attached to this post.
f1test
Posts: 15
Joined: Tue Nov 29, 2022 3:13 pm
Has thanked: 2 times
Been thanked: 11 times

Re: Managing large programs

Post by f1test »

Interesting idea, to use several devices to generate a single code.
Thank you for the advice
User avatar
Electroguard
Posts: 835
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 267 times
Been thanked: 317 times

Re: Managing large programs

Post by Electroguard »

It's not so much using multiple devices to generate code, more a matter of having an original source device (your esp8266) to reference for copying from as you generate your newer version on the esp32 device.

In my case, rather than starting new projects from scratch, I keep available any of the existing projects which I may need to collate code snippets from.
peridot
Posts: 46
Joined: Mon Mar 08, 2021 4:54 am
Has thanked: 7 times
Been thanked: 93 times

Re: Managing large programs

Post by peridot »

I tend not to used the built in editor except for small edits, I have found in the past I have got myself into trouble keeping my original code files up to date, so i have generally used an external editor and cut and past to upload code to the ESP device.

However since the introduction of the Local Save and Load buttons in the latest Annex versions, I have stumbled across a very satisfactory method for updating and loading code.
Being also a MMBasic coder for many years I have used the excellent MMEdit (written by Tassy Jim (Jim Hiley) of the Back Shed) as my main editor, Jim now has a Multi Window version of MMEdit which also works well as an editor for Annex RDS. MMEdit has many great features but one of its really welcome functions is its ability to "insert" code files , so making the addition of routines, code snippets or complete libraries quite easy, the included files may also have a ".inc" file extension. https://www.c-com.com.au/MMedit.htm

So to make the operation relatively seamless you will need to set the option in your browser regarding where you save downloads, to "Ask", this way you can nominate the folder you are currently using for your code. I use Firefox but I think all browsers will allow this, I also use windows but I assume Linux has a similar arrangement? So now you edit your code in MMEdit, save it locally then from the ESP editor you click the "Load a file from local computer" button, select your code file , load and save the file in the ESP. Simple edits can ofcourse be made directly on line and then the original file on your computer can be updated using the "Save a file to the local computer" button, you will need to reload your local copy of course.

There may be some tricks to this method but so far for me I think it is a very satisfactory arrangement.

Mike
Stuart
Posts: 126
Joined: Fri Feb 19, 2021 7:46 pm
Has thanked: 5 times
Been thanked: 20 times

Re: Managing large programs

Post by Stuart »

The other thing that I do that could save your sanity is to use Dropbox.

I too edit offline (except for minor fixes) and maintain all my files in a Dropbox folder that is automatically updated. I then copy and paste into Annex. I may copy and paste back if I have updated the working copy for some reason.

Using Dropbox means that I can go back to a previous edit when I have done something silly. Though it may take a bit of a hunt through many versions if you do a lot of edits. My Dropbox account keeps every saved copy for a month (I think, not having searched for anything more than a day or two old).

Every time I want to make a substantial change from a working version I save with an updated name, so I always have the undamaged most recent working version. Therefore I have every version ever saved kept offline and protected.

All very simple but good to have some discipline and a safety net.
Post Reply