Code can mean different things to different people. Here I will assume you mean the actual instructions and surrounding data that the CPU uses. Such a thing is a rather more advanced project than most start out hacking with but hey.
You can go active or you can go passive for this.
Passive would see you unpack the rom (ndstool, tinke, crystaltile2, ndsts... it matters little what you use for it) and get the ARM9.bin, ARM7.bin and any overlays. If for some reason you care about the code for a download play ROM then repeat process for utilty.bin (probably in dwc directory) or [something].srl you find the in the ROM as it is its own self contained ROM.
You may find the binary compressed, in which case BLZ from
https://www.romhacking.net/utilities/826/
ARM9 is the main workhorse in commercial games and does basically everything you expect to encounter in a game.
overlays are means of expanding the code, here a section of memory is set aside and you swap it out as the game requires. Typically this is for lesser used sections of code rather than something that runs all the time.
ARM7 is mostly just there to do some basic grunt work, and nothing really custom gets made for them such that you can find a game of a similar vintage and swap the ARM7 over having it work just the same. Some hackers however use this to include their own code with less concern for running out of space, time or other resources.
What you use to view the disassembled code is up to you as there are a thousand disassemblers out there for ARM of this vintage.
https://gbatemp.net/download/ndsdis2-ds-disassembler.28977/ for an old but basic one, better than objdump or whatever is in coding tools.
The previously mentioned crystaltile2 has one, and the ability to use NEF files that no$gba makes to bridge the gap a bit for active methods (coming shortly).
Various high end tools like IDA (you will need the paid version), ghidra and radare2 will be able to do things here as well, indeed tbhis is one of the few reasons to really go for passive approaches.
Active then. Mostly emulators and things that speak to emulators. The main perks are the ability to direct code, see active registers (knowing what is there, what modes, what flags...) and poke at it with a stick. By the time it is in memory it will be decompressed, unencrypted (not really a thing on the DS, is on other devices though) and such as well. The downsides tend to be complexity, in the case of emulators a limited range to view things vs being able to see the entire file trivially in static and having to translate it back to the files if you want to edit things (or suffer cheats as your applicator).
no$gba is a standalone debugger, and one of the better ones you will see in console world. NEF files mentioned above are I believe originally a Nintendo format that was recreated for this, and allow programmers to note addresses and other such things to allow assembly code to be more readable.
desmume more recently gained the ability to truly speak to GDB which means any debuggers that speak to GDB can be persuaded to interact with such things.
https://wrongbaud.github.io/posts/ghidra-debugger/ is for a GBA emulator but the principle holds.
https://book.rada.re/debugger/remote_gdb.html https://reverseengineering.stackexchange.com/questions/2270/remote-debugging-with-ida-and-gdb
melonds has a few things here but a bit more limited.
Don't bother with older things.
The DS was mostly written in C code which means it is open to some of the decompilation tools that are out there. How many are particularly trained on DS style ARM code is a different matter though, and very few DS hackers have done much of anything with it. Decompilation is one of those things that was kind of not expected to work (see halting problem) but actually does work in reality (see various N64 decompilations).
Also I believe some pokemon code got leaked with the gigaleaks a while back so you do also have that option if you want to go there.
I did see some hacks done with Rust a while back which was interesting, otherwise you get to write your own assembly code. I don't have a good guide to DS style ARM code so go with PC stuff
https://www.randallhyde.com/AssemblyLanguage/www.artofasm.com/index.html
https://stuff.pypt.lt/ggt80x86a/asm1.htm
and after that starts to sink in pivot back to ARM
https://problemkaputt.de/gbatek.htm#armcpureference
http://imrannazar.com/ARM-Opcode-Map
http://coranac.com/tonc/text/asm.htm is for the GBA but they are very closely related.
re poking code with a stick via active approaches.
So you have a static file that might speak to 4 megabytes of memory, you have no real idea what most of that does. Have fun.
Instead with active methods you might start by finding a cheat, say infinite HP. By finding the cheat you know where HP is for that particular aspect (probably an individual slot, might change by changing order even, such is left for the would be cheat maker to find). However anything touching that is going to be related to it and thus you can start to branch out, fill in some gaps and on and on and on until you have a greater understanding of things. If it sounds like it is going to take a long time then... yeah it will. Most then limit it to things they care about.
If you need a primer on cheats
https://doc.kodewerx.org/hacking_nds.html https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial
Debuggers then allow you to use something called breakpoints, the will halt emulation (or their cousins watchpoints/logpoints logging to a file) when certain conditions get met. Basic ones being when something is read, when something is written to or when something is executed aka the three basic operations memory can do. BPR, BPW and BPE or sometimes BOE respectively.
https://www.romhacking.net/documents/361/ covers a tracing session, the DS however sending cart read commands instead so you get to watch for those.
You need not find the direct thing you care about -- if the game alters graphics after an action (say jumping in a platformer) then hook into the graphics and work backwards, same for sounds, or watch what watches the controller state and go forwards from there if it is a button press.
