With the addition of include files to Mintoris Basic come many new wonderful and exciting prospects. We are now able to break large projects into smaller functional, and reusable, code files. And we are now free to use additional functionality without having to write the extra code, much like using libraries.
It is this area i wish to address. Since the include files will be written by different people than those using them, there should be some guidelines in place to reduce, or hopefully eliminate, variable and sub naming conflicts, sinc as if this writing, Mintoris Basic has no provisions for allowing private namespaces, so ALL global variables and ALL sub names share the same namespace, so duplications are not allowed.
These guidelines are suggestions only. It is not mandatory to use them. But… Using them will make life easier for all involved, including yourself.
1) Use global variables sparingly. This goes especially for those writing include files. Instead of global variables, consider passing info back and forth to your helper routines using arguments. Use global variables only when there is no other way to get it done. This cannot be stressed enough. The fewer global variables, the less chance of conflicts.
2) If you must use global variables, their name should be descriptive and meaningful. This goes for sub naming as well, because they are global too. Declaring short, simple variables as global is inviting disaster to your code, and possibly the code of others as well. The intent is to reduce the likelihood of having a global and local variable using the same name. As far as sub names go, this will reduce the likelihood of a sub in the main code body having the same name as a sub in the included code file.
3) Include file global variable and sub naming: A suggestion would be a 2-3 character author identifier, followed by a short, meaningful, discriptive name that identifies the purpose or intent of the include file, followed by a short discriptive name that identifies the purpose of the individual global variable or sub. I use this strategy when naming any element that's publicly exposed in the globally. An example: I wrote an include file called wsRC4.bas, to give the user encryption capabilities in their code. My author identifier is 'ws' which identifies my software company WarSOFT Apps. The name of the purpose is 'RC4'. It has two subs, wsRC4CreateKey$() and wsRC4Encrypt$(). See how using this naming technique dramatically reduces the likelihood of accidentally using the same sub name in two places? Also remember that since there is no provision for private subs, even your helper subs that would normally be declared as private should be named in this way as well, because they too are public. The wsRC4 library uses no global variables, but if it did, they would use the same technique. If a global variable just had to be used, to store the generated key for example, it'd be named wsRC4Key$.
4) Keep local and non-global, general purpose variable names short and simple. They can be discriptive if need be, but should be kept as short as possible. This will help prevent duplicate name conflicts between the global and local namespaces.
Thank you for bearing with me. Remember these suggestions are just that. Suggestions‥ If any other techniques help in this situation, please post them here. Also please feel free to discuss these here.