|
Post by sarossell on Dec 31, 2019 3:10:30 GMT -5
True BASIC had a neat feature that made all variables before the End command global so that functions could be included before the End command and all variables inside and out of the functons would be global, but any functions after the End command maintained local variables. Any chance that might be a consideration for LB5?
|
|
|
Post by Rod on Dec 31, 2019 3:23:53 GMT -5
Ugg... explicit, minimal global variables seems a step ahead of that.
|
|
|
Post by Carl Gundel on Dec 31, 2019 7:21:53 GMT -5
True BASIC had a neat feature that made all variables before the End command global so that functions could be included before the End command and all variables inside and out of the functons would be global, but any functions after the End command maintained local variables. Any chance that might be a consideration for LB5? I’m not sure what the appeal of that would be. It surprises me that True BASIC does anything like that. It’s a much better idea in my mind to require globals to be declared explicitly.
|
|
|
Post by mknarr on Dec 31, 2019 10:28:58 GMT -5
I agree and when I code I make all Global variables all upper case. That way I always know when a variable is global today, tomorrow and next year or 5 years from now.
|
|
|
Post by sarossell on Dec 31, 2019 11:00:40 GMT -5
LOL. I'm guessing this is an unpopular idea. Come to think of it, my earlier reasoning was based on function and subroutine collision in program flow, but that's not an issue anymore. I'm showing my age again. Fair enough. I've seen the light, Brothers. Thanks for saving me from myself.
|
|
|
Post by Carl Gundel on Dec 31, 2019 19:26:07 GMT -5
I agree and when I code I make all Global variables all upper case. That way I always know when a variable is global today, tomorrow and next year or 5 years from now. The idea of having an option to make capitalized variables automatically global is an interesting one. In a situation like that I would imagine some sort of compiler directive such as: compiler globals_uppercased Just throwing that idea against the wall for discussion.
|
|
|
Post by sarossell on Jan 1, 2020 2:28:32 GMT -5
I'm sure the more experienced programmers can provide intelligent reasons for agreeing with the idea of capitalized globals, but I have a terrible time with case and have had to resort to preceding global variables with "g." (e.g., g.rotations). I'm not in any way suggesting my method is best, good, or even remotely advisable. It just works for me.
I also use "v." for regular variables, "f." for functions, and "s." for subroutines. It's a habit I developed when running against variable names that were reserved keywords. This way, I can always be safe creating names like v.step, g.input, s.quit, f.print, etc.
Again, I'm not saying this is a good idea. I learned a lot of bad habits over the years as a result of working with Sinclair and Gfa BASIC.
:@)
|
|
|
Post by Rod on Jan 1, 2020 4:23:11 GMT -5
I am not a fan of full capitalisation. We have syntax coloring that helps for commands, I hate to see fully capitalised commands. Leading letter capitalisation I could live with, automatic globalisation of such variables would be slick and force more of us to standard, lower case, writing which I find much easier to read. The preceding x. idea is interesting but xpos and Xpos is an easy way to define two variables with one character.
|
|
|
Post by mknarr on Jan 1, 2020 10:23:18 GMT -5
Rod, I think everyone has their own style. Globals are all caps. Variables that have to mean something might be ThisGoesFirst$ but variables used within a section will be lower case such as for x=1 to y. Variables in a file are always Something.Else and arrays always start with a cap. Just my way after about 50 years of programing in different basics and 15 years with LB. Yes I'm old and I need every bit of help I can get.
Yes we have syntax coloring but all variables are green.
|
|
|
Post by Rod on Jan 1, 2020 11:35:13 GMT -5
I suppose if the leading character was the trigger you could do full capitalisation if you wished., camel hump capitalisation would still be ok provided the leading character was lowercase. For local scope.
|
|
|
Post by sarossell on Jan 1, 2020 12:09:48 GMT -5
Rod: That sounds pretty cool. I could continue to be a weirdo and use my "x." notation method by just using a capital "G." for global variables. Meanwhile, real programmers can simply use camelCase for local variables and PascalCase for globals.
|
|
|
Post by Brandon Parker on Jan 11, 2020 17:56:03 GMT -5
No matter the style being used, the biggest thing one needs to do in hobby/professional programming is simply be consistent across a project. Everyone has their own style of capitalization and formatting, and everyone else wants to criticize others' style, but in the end consistency is KEY.
{:0)
Brandon Parker
|
|