You have your answer in the other post. What I would say is that if you are designing reusable code, then the level of detail you need to put in is far more than for a normal program. This code you create affects multiple programs possibly across whole companies depending on what it is used for. The reason I mentioned this is because I saw what you had posted:
%macro loan(dataset,items); proc means data=&dataset; var &items; %mend; %loan(loantarget,loan);
And you have fallen into quite a few pitfalls. Firstly and most importantly is the why. Proc means is well known Base SAS procedure which all SAS programmers know about. The question of why, is why are you hiding that well known bit of code in a macro, especially with a irrelevant name like loan() which has no bearing on the code? You will notice this when you join a new company and they have massive macro libraries dating back to the stone age and the programs look like:
%let %sysfunc(%amacro(&&&var_notdefined..%x___(&&qbc))));
(note thats just someting I typed here to illustrate), care to debug that. Me I just delete it now. So in your case, someone else comes into you role 5 years from now, not knowing what you know and they look at your code:
%loan(lastname,something else other);
%loan(firstname,something else other);
What does the above code do?
It is called obfuscation, and Macro is, in almost 99% of the time used in this manner. If its just one program, maybe fine, if its code used in 30 countries around the world by lots of users, not so much.
So take time in crafting well documented - 99.9% of programming is documentation - validated, worthwhile code. Use relateable names, use named parameters, indent code to make it readable, finish code blocks with run;. In this case I would just put the text of the proc means in your program, is it worth creating a debug nightmare just to save typing those few characters?
... View more