Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
Nimue Guru Joined: 06/08/2020 Location: United KingdomPosts: 425
Posted: 09:18am 13 Sep 2020
Copy link to clipboard
Print this post
Recent discussions on arrays and reusable code has led me to investigate the use of .inc files.
This has led me to realise that I don't fully understand the syntax / rules of the game with respect to using .inc
either: Is there a resource on line I can find that will help?
or: Can someone provide me with some pointers
Context Am looking to set students a distributed task to each write a function, which we will combine into a .inc file -- but I need to know the rules they need to work to.
I guess this touches on the array discussion over reusable code in general -- what are the good practises that I need to follow?
Cheers NimEntropy is not what it used to be
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10582
Posted: 09:31am 13 Sep 2020
Copy link to clipboard
Print this post
Nothing to onerous.
I would recommend that you mandate OPTION EXPLICIT and OPTION DEFAULT NONE. Then if you are going to use any non-default options you should mandate those as well (e.g. OPTION ANGLE) but try and stick to defaults as much as possible.
The functions should be self contained and only use LOCAL variables or the variables passed in as parameters. Use meaningful variable names. I don't personally subscribe to attaching the function name to the front of the variable name (myfunc.myvar) but others do.
Decide if you are going to use variables with explicit typing (%, !, or $) or allow typing to be set in the DIM statement and mandate that - personally I would recommend explicit typing for your application.
The function should of course be fully documented with comments defining the calling sequence, expected inputs and outputs etc. Remember function parameters are passed by reference so the documentation should be explicit if it changes a parameter although this should be discouraged with the sole exception of arrays as unfortunately MMBasic functions can't use arrays as the function return. Edited 2020-09-13 19:36 by matherp
Nimue Guru Joined: 06/08/2020 Location: United KingdomPosts: 425
Posted: 09:35am 13 Sep 2020
Copy link to clipboard
Print this post
Thanks for the feedback.
From above -- those in the main body of the code, not in the .inc file?
If Option was used in an .inc file - is the scope just the .inc? (or am I missing the point?)
I appreciate I probably just need to dive in and spend a few hours having a go ;-)
NEntropy is not what it used to be
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10582
Posted: 09:38am 13 Sep 2020
Copy link to clipboard
Print this post
Yes, right at the top of the main code. I assume each student will write a small main program as a test harness for his/her code.
Nimue Guru Joined: 06/08/2020 Location: United KingdomPosts: 425
Posted: 09:39am 13 Sep 2020
Copy link to clipboard
Print this post
Thanks.
Will have a play, sorry -- investigate and post some examples of what they acheive.
NimEntropy is not what it used to be
mkopack73 Senior Member Joined: 03/07/2020 Location: United StatesPosts: 261
Posted: 01:48pm 13 Sep 2020
Copy link to clipboard
Print this post
Like Peter said, it's pretty straightforward. Think of an include as "additional code that gets inserted on the fly" into your program. Now that can make things a bit messy if the code inside the .inc is written with one set of options set and the calling main program (the one that makes the .inc call) uses a different, you'll get errors.
So, like stated, mandate that the code in the .inc is written to a given set of option rules (for ALL of the options) and make the main program set those settings at the start (before the include call, don't put those in the .inc file)
Usually when I'm writing a .inc I'll write it as a .bas, put any special stuff I need to make it work as a full program near the top (like the options, any little test main program etc) and then once I have the functions I'm sharing all working then I'll comment out the stuff at the top that won't be needed when its an include (I don't delete it in case I need to go back and fix something and need that for driving debugging) and rename it to a .inc.
Then in your main code, you just call the functions and subroutines inside the .inc as though they were right in your program's .bas file (they're just living in another file which you included on the fly).
That's it! Pretty easy!
Like I said in the other thread, the complications come if you write your .inc using one set of option rules and the calling program uses another. There ARE ways to deal with this, but it requires extra work on the .inc file author to handle it.
mkopack73 Senior Member Joined: 03/07/2020 Location: United StatesPosts: 261
Posted: 01:50pm 13 Sep 2020
Copy link to clipboard
Print this post
So for like a simple example, write your program, and put something into a function that the main program calls.
Now strip that function out of the .bas file and put it into the .inc file.
Add the line to the main .bas file to do the include "myfunction.inc"
Run the .bas and it should work just like it did when the function was inside the .bas file!
Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
Print this post
