Some things missing from the other answers.
Step1. Don't use Macros. From your other posts here I'm assuming you are very new to 6502. In the "One must crawl before they can walk", macros are "Running with scissors". I call them Mermaids, you need to be able to look at a macro and see through it, be able to write the code that it writes for you. I know they are lovely and make the code faster and neater and oh so handy... they will eat you alive! Every time you use a Macro you must give it a long hard stare and say "will this bite me", and the way you learn this is by writing the code behind them each time again and again and again and again and again.. then in say 1.5 years from now you will be able to start using them, because by then you will have written all the code pieces so many times, you will be able to do it by rote and when you slap down a nice macro you will be able to read the code in the macro as you scan your code. However even then you will still made the odd stupid mistake with them..
Code:
.macro somemacro
.local @endofmacro:
.local @macrovar1
.local @macrovar2
; code in here doesn't really matter
sta @macrovar1
lda some_global
clc
adc #28
sta some_global
lda @macrovar1
; end of main macro code
jmp @endofmacro
; start of macro local variables
@macrovar1: .byte #$00
@macrovar2: .byte #$00
@endofmacro:
.endmacro
Macros are not standard, each assembler does it in its own way. So this may make a unique instance of each macrovar per use of the macro. Which may or may not eat RAM like no tomorrow and force you in to a massive rework at some point, even on a C64 where you have an insane 64K of contiguous RAM. You may also use it so much that the assembler runs out of the 2K on the NES and enters into mapping them in the RAM Mirror trashing other memory locations
OR
Your assembler may only make one instance of the vars due to how it instances and sorts it macro code so all instances of the macro only use 1 set. Sounds great, what could possibly go wrong...
Code:
..normal code
#myMacro
..more normal code
ISR
..ISR code
#myMacro
...more ISR code
Can we spot the horrible bug waiting to happen??? What if the interrupt just so happens to fire during somewhere in the middle of #myMacro, then the #myMacro in the ISR happens, TRASHES some var inside the macro and boy do you have a fun bug to trace...
They are mermaids, don't swim with them until you really really know what you are doing.
When I program on my C128 then using Macros really helps, as I can store them on a file in the disk and so they don't eat up my RAM, they make it slow to assemble but not slower than making 3 files to assemble at once. They also let me fit a LOT more code on my 25 line high screen. And Ctrl+C and Ctrl+V wasn't invented yet, although my editors do have copy and paste its clunky, I don't have a mouse and I don't have "search as I type" meaning, typing a Macro makes it so much easier for me. On a modern day pc with mouse, Ctrl+C, V and oh 1GB of RAM and Code folding. No need, that can assemble a whole 512K cart in 2 seconds, not a huge issue. My point is you don't need Macros yet, you can copy paste, use snippets and other modern tools to get the quality of life, without getting bitten.
However How do you stop functions from trashing things..
You can't welcome to Assembly.
Naming conventions may help as you form your "style", for example if you have a function that trashes x,y you may wish to name it such
myFunc_xy
myFunc_t123 ; trashes temp 1,2,3
Overtime however you will generate a coding style and you will learn to stick to it, where you will form your own conventions and this will mostly be shaped buy how many times and by what you get bitten by.