By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,847 Members | 3,068 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,847 IT Pros & Developers. It's quick & easy.

Named vs Un-Named arguments in code

Expert 100+
P: 1,430

What is there an advantage of using your syntax instead of:-

Expand|Select|Wrap|Line Numbers
  1. DoCmd.CloseObject acForm, Me.Name, acSaveNo
Aug 11 '18 #1
Share this Question
Share on Google+
3 Replies

Expert Mod 5K+
P: 5,331
named arguments vs un-named arguments
- Mainly a personal preference and for simple commands perhaps a bit redundant; however, for me I find that:
1) The order doesn't matter doesn't matter
+ DoCmd.Close ObjectName:=Me.Name, ObjectType:=acForm, Save:=acSaveNo
+ DoCmd.Close Save:=acSaveNo, ObjectType:=acForm,ObjectName:=Me.Name
+ DoCmd.Close ObjectType:=acForm,ObjectName:=Me.Name Save:=acSaveNo

Can't count the number of times when I've been in a hurry that I've started with the Title for a msgbox because that was what I was thinking about at that moment in time.
As of late I've been using the err.Raise method in my code so that my error-handler will take care of messages and drop to the clean-up if certain conditions are not handled so I have a Select-Case in these types of error traps with things like:
Expand|Select|Wrap|Line Numbers
  1. zStrMsg = Err.Number & vbcrlf & Err.Source & vbcrlf & Err.Description
  2. '(...)
  3. zStrMsg = zStrMsg & vbcrlf & "Do you want to override and commit action? (default [No])"
  4. '
  5. MsgBox Title:="Oh No Action is Prohibited!", Prompt:= zStrMsg, Buttons:= vbCritical+vbYesNo+vbDefaultButton2
I like to start with the title as it's an abstract of what the MsgBox is for in that context without having to dig back through my code for "(vbObjectError + 1)".

2) It makes it clear what your intent is/was (i.e: Err.Raise/MsgBox) for anyone following you for code maintenance without having to find the syntax reference for more complex code (I work with a lot of individuals that do not know nor care to learn any programing language - I'm a chemist by trade/training with a bit of math, (chem/civil)engineering, and compsci tossed in for spice)

3) You can do this:
DoCmd.OpenForm FormName:="SomeFrmName",OpenArgs:="StringHere"

Instead of
DoCmd.OpenForm "SomeFrmName",,,,,,"StringHere"
is The String a WhereCondition or a Open arguments
For example
DoCmd.OpenForm "SomeFrmName",,,,,,"Monkey=Chimp"
DoCmd.OpenForm "SomeFrmName",WhereCondition:="Monkey='Chimp'"
While in one you could be troubleshooting for a "Month" if you thought you were passing a WhereCondtion clause in the second the intent is clear AND you know you need that extra set of quotes (yes, I've seen this done - extra/missing comma makes a difference - have you accidently deleted a comma and the code that was working stopped - ARRRGH)! Also, IMVHO, it makes the code cleaner by removing all of those placeholders.

4)When explaining syntax to a inexperience user without the benefit of face-to-face it prevents any ambiguity in the explanation.
Aug 11 '18 #2

Expert 100+
P: 1,430
Yes, that makes a lot of sense, especially the OpenForm and equally when passing optional arguments to functions.

Never too old to learn?????

Thanks for that,

Aug 11 '18 #3

Expert Mod 15k+
P: 31,307
Very big fan of using named arguments in my code. There are some exceptions - principally when the variables used in the calling code already match those in the called procedure definition, but also extremely common procedures with only one, or maybe two at most, parameters.

It's particularly helpful when working on here as it's explicit. Most of those who are still learning need explicit. They don't need to fall over those missing or extra commas (,) so prevalent in positional parameter code.
Aug 11 '18 #4

Post your reply

Sign in to post your reply or Sign up for a free account.