This is an interesting question, especially with the focus on the macro user:
Do you apply a naming convention for macro parameter names, names which are meaningful for the end user?
On the one hand, as a macro developer, I think this is an important question, and one we should all consider.
On the other hand, as a SAS user, I feel like finding the best answer and using it consistently doesn't matter that much. Even if you are developing something like a corporate macro library, where one might think that consistency in macro parameter names might be very important and helpful, the truth in SAS programming is that you end up using macros from a variety of sources, that all have different naming styles. So as macro user, you are used to having to look at macro code to figure out the parameters etc.
That said, I do think there is value in using consistent names, partly as help to the user, and partly as help to the developer.
I often have a macro parameter PATH, for:
B: C:/mydir/mysubdir
C: C:/mydir/mysubdir/
I'm inconsistent about whether or not the value passed to PATH should end with a trailing /. Generally I think it "should". But in the macro code, I don't really like the look of:
&path&file
I just like the look of:
&path/&file
I think Windows and Linux may not care about //, even if it looks weird. As Tom said, the best answer for path is to allow the user to pass a value with our without trailing /, and have the macro accommodate it.
I also often have a parameter named FILE for:
A: C:/mydir/mysubdir/helloworld.xlsx
hiworld (this is a fileref, not the name of a file without an extension)
F: hellowworld.xlsx
Usually the value to be passed for FILE is either a full path to a file, or a fileref (the user can choose). It's rare that I would pass just a file name (helloworld.xlsx). But if a macro has a PATH parameter, then it's possible that a FILE parameter would be just a file name, because the user has already specified the path to the file. It doesn't bother me that a FILE parameter could be the full path to the file, just the filename, or a fileref.
On occasion I have a parameter EXT or EXTENSION:
H: xlsx
There were probably times when I would ask a user to include a dot in the extension, but to my mind the dot is not part on an extension. But like trailing / issue for path, for a user-friendly macro it's trivial to detect whether the user has provided a leading dot or not, and handle it accordingly. So you don't need different parameter names for EXTwithDot EXTwithoutDot.
I don't think I've ever written a macro parameter that asked a user to provide a value for a file name without an extension:
D C:/mydir/mysubdir/helloworld
E: helloworld
Just looking at those, the first value looks like a path, and the second looks like a directory or subdirectory to me, these values don't look like files.
So if I were to pick a standard I use inconsistently, it would be FILE, PATH, and EXT. But if you looked at macros I've developed, you'd find plenty of FILENAME, INFILE, DIR, FOLDER, etc.
As IDE's get smarter, they make some of this easier for the user. For example in EG, if you define a macro like:
%macro foo(
path= /*path to file, with trailing / */
,file= /*file name in quotes with extension or fileref*/
);
%* ... ;
%mend foo;
When a user invokes the macro, some of those tips will be available. It's not perfect, but it's something. I don't know if there is something like that in Studio, or the VS code extension, but would hope so.
... View more
