11-25-2022, 06:40 PM
(11-24-2022, 11:33 PM)TerryRitchie Wrote: I never understood why new concepts and commands are sometimes looked upon as changing the old ways, especially for something useful like OPTION _EXPLICIT.
I use it because it makes coding easier. The first time I encountered a high-level language that forced variable declaration (Turbo Pascal 3.01) I was hooked. It's just a no-brainer to have such a mechanism in place in my opinion of course.
Option _Explicit!!
HSSSSSS!!! EVIL!!
All kidding aside, me and Option _Explicit just aren't compatible. It's not that I'm against learning new ways; it's just that it doesn't suit my coding style with the rules it enforces.
Where me and Option _Explicit have our irreconcilable differences comes from this type of code:
Code: (Select All)
SUB whatever
SHARED x, y, z
Since QB64 requires $INLCUDE code to be broken down into two modules -- *.BI and *.BM -- I usually tend to try and get around this with a simple SHARED statement when all I need to do is share a few variables between my library's subs and functions.
Option _Explicit, however, doesn't think that SHARED inside a sub/function counts as a valid declaration for the variable type in question. It wants you to DIM x, y, z inside the main module, before it ever shows up in the subs or functions...
...and that kind of defeats the whole purpose of trying to use SHARED to reduce $INCLUDE files down to a single file, rather than having two of them.
Somehow, it just seems kind of silly to me to have this for "My_Example_Library.BI", just so it'll stay valid with Option _Explicit:
Code: (Select All)
DIM x, y, z
Personally, I've just came to the conclusion that me and it just aren't meant to work together.