When explaining code, you need to paint with broad strokes. There are all sorts of nuances that would normally require extensive and careful explanations, but what you really want to do is a kind of ELI5 approach, then go into more detail if people ask for it (they almost never do).

It also helps to just keep practicing, getting feedback afterwards (people don't usually want to give feedback, but I've had success prefacing it with "I'm trying to improve my explanations, so solid feedback on anything that was confusing will really help!").

- it will help you stay focused, plan a good sequence of points for your audience, a tour. What are they supposed to learn or know after this?

- architecture &| organization (with a diagram)

- highlight important areas of the code

- show flow from entrypoint(s) to important areas

- do not go line by line, do not go into the weeds

- do know your audience and craft it for what they are trying / need to learn from it. You are not trying to make them contributors most likely

- talk about the whys, not the hows

- don't fill the slides with text or code, put more text into the speaker notes if necessary (but avoid as much as possible) use links to code rather than code screenshots in the slides (exceptions)

If you want to get better, do it as much as possible. Practice makes perfect as they say, though it is never perfect in reality.

I love the bullet point list. I'll keep this bookmarked for next time. =)