checking parameters passed into a function

[DaveT1]

I'm not sure whether what I'm trying to do makes sense. So I'm reaching out in the hope that those with more understanding can (gently) put me on the right path:

At the start of a user-defined function, I feel that what I should do is, for each passed paramter, check its type and that its value is allowable. Consider pseudo code below:

Code: Select all

WriteFuncLabelCallSequenceToFile(psCallingFuncLabelName, piFlag, psScriptName:="")
{	
;===Error check the parameters===

If (psCallingFuncLabelName is not alpha)
	MsgBox, The variable %psCallingFuncLabelName% should be type alpha in %A_ThisFunc% (line %A_LineNumber%), but is not.
If (psScriptName is not alpha)
	MsgBox, %psScriptName% should be type alpha in %A_ThisFunc% (line %A_LineNumber%), but is not.
If (piFlag is not integer)
	MsgBox, %pParam1% should be type integer in %A_ThisFunc% (line %A_LineNumber%), but is not.
if piFlag not between -1 and 1
    MsgBox, %piFlag % is not in the range -1 to 1, inclusive.

; more of the function's code here
    
return
}

Firstly, is this a sensible thing to do? It strikes me as a good idea to have these sorts of checks to defend against passing in parameters from the caller of the wrong type and / or value.

Assuming this approach is basically OK, I can see how type checking might work for most types, but not easily for strings (which is what the first 2 type checks above do). What happens if my passed parameter is a combination of chars and spaces - eg., "Here we_are 12345" - how to test that this is a string?

Grateful for any advice, specific to the question, or more generally on checks of this nature.

[MannyKSoSo]

If this is a function that will be given to user's its not a bad idea to have checks for what is correct. If you will be the only one using it, then a simple note above the function would be perfectly acceptable as well. Also you should throw errors instead of a msgbox as that function shouldn't execute if its not correct. A lot of the people who make functions for everyone in this community generally put info above their function calls telling the user what the function does, the kinds of inputs it accepts, and the outputs to expect. An example of this is https://github.com/denolfe/AutoHotkey/blob/master/lib/xml.ahk which has the info above each function as well as some checks to make sure the info passed into it is correct.

[DaveT1]

Thanks @MannyKSoSo. I had actually removed comments describing the nature of the function, params, return values, etc., just to make the Q a little more focussed - probably shouldn't have!

Totally agree about throwing an error - the msgbox was intended to show 'do something sensible here', but it was the testing above (IF, etc) that I was more interested in finding out how / whether to do.

Thanks for the link. Even though commenting there not laid out how I would do it (v. minor issue), it's very strightforward to work out what's going on and that's always the main thing.

In summary, if using a function yourself, good, self-consistent comments should suffice. If making the function public, do more?

[boiler]

In summary, if using a function yourself, good, self-consistent comments should suffice. If making the function public, do more?

Another consideration is the source of the data that will become the input parameters to the function even if you’re only calling the function yourself. For example, if you’re passing the value of a variable that was read from a user file or something that a user entered into a GUI form, checking the validity of the data as you have outlined is a good idea. In cases where the values of parameters are controlled by the code itself, then you don’t necessarily need to check the data as you presumably are making sure everything is kosher as you test and debug the code.

[DaveT1]

Another consideration is the source of the data that will become the input parameters...

@boiler this is a great point - thanks for raising it. In this case though, should you test the data (type and permitted values) at the point they were read / entered?

...presumably are making sure everything is kosher as you test and debug the code.

Hmm, I'd like to think that I'm that good, but a big reason for asking the question is to see how best to defend me against myself

Re: testing for type - how to test a var to see if it is a string as opposed to just type=alpha which might be too restrictive?

Thanks for all the great pointers .

[boiler]

In this case though, should you test the data (type and permitted values) at the point they were read / entered?

That's certainly a good option. Depending on the purpose of the function, it might be the first action taken after reading in the data and would make sense for that to be that point to check them.

---

Hmm, I'd like to think that I'm that good, but a big reason for asking the question is to see how best to defend me against myself

Yes, but you have AHK's error messages and viewing the output of running the script to see that all of your code is valid. Presumably, the script either won't run or won't run correctly if you make such a mistake and it would become obvious. Once you get all the typos out, it's not like they can reappear in the future, so carrying data-checking code in your script (and the time to write it) is sort of a waste.

---

Re: testing for type - how to test a var to see if it is a string as opposed to just type=alpha which might be too restrictive?

Since any AHK variable can be treated as a string, there's not a test that will really tell you it's not a string. However, it sounds like you mean anything that's not a number should be considered a string, so you can use if Var is not Number, like this:

Code: Select all

InputBox, Text, String Check, Enter text:,, 300, 140
if Text is not number
	MsgBox, "%Text%" is a string
else
	MsgBox, "%Text%" is a number

[DaveT1]

@boiler thanks so much. Your observations have helped lift the mist of confusion. I'm going to better digest your observations and see what these imply for my coding practices. Thanks again .

[boiler]

Sure. Just my opinions, and others may have other and better thoughts, but that's based on my experience.