Quick question - I've got into the habit of using Define for local variables at the start of a procedure, but I notice from the help and other code examples that people often use Protected instead. So, where I have:
Procedure Something(param.l)
Protected somevar.l
; do stuff...
EndProcedure
Is Protected a better approach to use, and if so why? Also, would there by any issues in doing a search and replace for these on an existing program?
(The help mentions that Protected avoids problems where a global variable matches a local one - in my own code I always use a different naming convention for globals, so this doesn't arise.)
Define makes no sense in a procedure. You should only use Protected, Static, Shared, Dim, NewList ...
but not: Global, Define in a procedure. You can do this, but is not a good style.
PureBasic 5.73 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
Ok, thanks for that, it's rather the answer I was expecting.
Would you expect any issues with just doing a search and replace on my existing programs?
Also - no globals in procedures? I currently tend to have an InitGlobals() that gets called early on and does all the Global stuff I need doing. Is this also bad style?
Probably it's better to avoid the use of define inside a proc, for clarity.
With 'protected', you are making clear to the reader a certain var is local to the proc no matter what, even if you declare the var when a global with the same name is already declared.
In fact, if you try to use 'define' to do the same you get an error (something about same var already declared with a different scope).
Excluding this case, 'define' and 'protected' seems to act the same way inside a proc, the code generated is the same for what I saw.
mikejs wrote:
Would you expect any issues with just doing a search and replace on my existing programs?
Depend on how you used define, it can be used to define defaults type for example, so you can't substitute that blindly, or you can have used it outside a proc, again you can't substitute that blindly. I would never do a blind search/replace.
mikejs wrote:
Also - no globals in procedures? I currently tend to have an InitGlobals() that gets called early on and does all the Global stuff I need doing. Is this also bad style?
It's generally considered "bad" to have globals scattered everywhere in the program, for obvious reasons, if you put them in a single place easy to find and maintain I don't see a problem.
mikejs wrote:Also - no globals in procedures? I currently tend to have an InitGlobals() that gets called early on and does all the Global stuff I need doing. Is this also bad style?
If you define all globals in one procedure, it is not a bad style.
All define of globals should in one place, "near the top" of source, for clarity.
"near the top" = After or before "IncludeFiles" for Scooping!
PureBasic 5.73 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
mikejs wrote:Also - no globals in procedures? I currently tend to have an InitGlobals() that gets called early on and does all the Global stuff I need doing. Is this also bad style?
If you define all globals in one procedure, it is not a bad style.
All define of globals should in one place, "near the top" of source, for clarity.
"near the top" = After or before "IncludeFiles" for Scooping!
It's also a very good idea to put all globals inside a globally declared structure, that way you'll get some additional benefits from the autocomplete feature.
mikejs wrote:Also - no globals in procedures? I currently tend to have an InitGlobals() that gets called early on and does all the Global stuff I need doing. Is this also bad style?
If you define all globals in one procedure, it is not a bad style.
All define of globals should in one place, "near the top" of source, for clarity.
"near the top" = After or before "IncludeFiles" for Scooping!
It's also a very good idea to put all globals inside a globally declared structure, that way you'll get some additional benefits from the autocomplete feature.
And also your program will be easier to extend. Assume your program handles documents. If you use global variables for the document information, you'll have a hard time changing the program to allow multiple documents at a time (like in a tabbed interface). If you have globals in a structured variable, it will be easier.
I have never seen a local structure
Structure, Prototype, Constant are allways Global and don't put it in a procedure, is a bad style.
This are no variables!
PureBasic 5.73 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
skywalk wrote:I agree, so shouldn't it be flagged as a Syntax Error by the compiler?
bad style <> Syntax Error.
Give the user the freedom to decide for himself
PureBasic 5.73 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
Fair enough.
I'll put a request for the Manual pages to state "Structures defined in Procedures are always Global".
It seems weird to allow this and I don't see the point?
skywalk wrote:Fair enough.
I'll put a request for the Manual pages to state "Structures defined in Procedures are always Global".
It seems weird to allow this and I don't see the point?
PureBasic structures aren't global, they're scopeless (the same is with constants). Scoped structures might make sense but I think there are more useful things to implement to the language (like modules/namespaces).