Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Params compatibility with initialisation variables #18

Open
Windmolders opened this issue Jul 20, 2016 · 6 comments
Open

Params compatibility with initialisation variables #18

Windmolders opened this issue Jul 20, 2016 · 6 comments

Comments

@Windmolders
Copy link

Would it be possible to add variable initialisation recognition for parameters?

example:

_ZCP_RWB_data is marked as an UNinitialized variable

params
[
    "_ZCP_RWB_data",
    "_ZCP_RWB_boxType"
];

private _ZCP_RWB_currentCapper = _ZCP_RWB_data select 0;
@kayler-renslow
Copy link
Owner

It is already in place. For instance:

params [["_xb", 1]]; //initialized
params ["_hello"]; //uninitialized

The issue I suppose is finding when the param is set outside the function code, like this scenario:

[123] call {
    params ["_myvar"];
};

This gets very complex to detect. I may put in place something to detect it, but the best way of making sure your code is robust is explicitly defining your variables inside the function. (e.g. params [["_var"], 1])

@BangL
Copy link

BangL commented Jul 21, 2016

if you really want your param be nil by default, you can also set nil explicitly to mute the IDE.
like this: params [["_hello", nil]]; // still nil, but no warning

@BangL
Copy link

BangL commented Jul 21, 2016

by the way:

and to make your functions even more robust, you should also whitelist types like this:
params [["_hello", nil, ["", 0]]];
this example allows strings and numbers as first param, while still beeing unitializied by default.
having no bracket there basically means "allow any type here"

@kayler-renslow
Copy link
Owner

There is now a check for nil values.

@BangL
Copy link

BangL commented Jul 22, 2016

do you mean youre showing those as warning now as well? :O
please don't ... i mean there are cases where i want nil. it was perfect in my opinion.... when i forget to set a default it warns me, and if i say explicit its nil then its fine.

@BangL
Copy link

BangL commented Jul 22, 2016

but technically nil means undefined, so actually youre right. damnit

@kayler-renslow kayler-renslow removed the bug label Oct 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants