Sorry your browser is not supported!

How can it be so that AppGameKit doesn't seem to manage function parameters as local variables? The following code works fine when not using #option_explicit but with that gives an error "main.agc:11: error: "max" is already being used as a function name"

There is no sure way for AppGameKit to know if you intend on using max as a variable, or as a function. Remember that function names are within the scope of other functions. Without#option_explicit, AppGameKit makes an assumption that you mean the local variable instead of the function. The assumption would probably be right 98% of the time, but could be a difficult to find bug in the other 2%. With#option_explicit, you are telling AppGameKit to not make any assumptions, instead you are going to make a conscious and explicit difference between the two, and it should flag as error anything else.

Hmm, doesn't make sense to me as the compiler should know it's a variable in function definition and valid within function scope. Anyhow this is relatively easy to avoid by using prefix for function parameters (e.g. "p_").

Interestingly the same thing seems to apply in qbasic is as well so maybe it's part of the Basic "standard"

It doesn't make sense because your example above is simple and the intent is obvious. As the project gets larger, more people join the team, you #include and c/p other code into your project, the likelihood of naming conflicts increase. Before you know it, what seems obvious to you becomes ambiguous to the compiler.

Remember that the compiler actually knows nothing. When presented with two possibilities, it simply picks one based on various parameters and rules. If you have a variable called AlphaOne, and the code you #include, written by someone on the forum, also has a variable called AlphaOne, and the rules of the compiler has it choosing the #include version, you might be scratching your head for quite a while wondering why your program compiles but behaves incorrectly until you open the other file and realize that it also has the same variable.

By using #option_explicit, you are telling the compiler that you, as the developer, will explicitly prevent ambiguities by using unique identifiers for all the variables that share the same scope, and explicitly define their types before you first use them. Anything else is an error. This might create a bit of extra typing, and more diligence when creating new identifiers, but the extra time used to program will usually be returned by less time debugging. Quite often, once you resolve all the compiler errors, the program will work correctly the first run.

Of course, this really comes down to your preference as a developer. Many don't want to "interrupt the flow" of their creativity by concerning themselves with those details and would rather take the time to deal with the bugs after they are through programming, so they choose not to use #option_explicit. Personally, I have found if you try to use it all the time, it will become part of the "flow" and does more to help than to hinder.

AGK's #option_explicit can be a real PITA sometimes and this example highlights the pitfalls of using it, but that being said it can also help in avoiding hard to find bugs or unexpected behaviour, its a payoff between "do really prefix all my vars or do run the risk of spending 3 days tracking down a bug"

the above code..... the compiler should be checking for a function call before it moans that its a function name, maybe its checking global scope before local, either way it is odd!

Is there even such a thing as a non-global function?

Yes, but not in AGK