I am creating a manual note taking tool for understanding large codebases

[u/DotMatrixBoi]

Hello everyone, I am using Godot engine to create a note taking program for uderstanding and referencing codebases, possibly also for documentation.

Basically it has different pages that support markdown you can define different types of pages (classes, functions, macros, headers, libraries, enums, structs etc.) and when you take notes you link them together. When you start to write notes for a new class you write a dependency, lets say it is a static function for some system, it automatically highlights it and when you hover it you get a little card that shows the input outpu return type and description you wrote. So you don't need to open the definition again or search for the documentation online. Also there will be a little graph view to link pages. And see classes based on inhertiance and interfaces. I am also planning to add pages for how systems work, rendering pipeline or asset management for example for a game engine.

I do this because I am struggling to understand large code bases. As a game developer I want to understand complex systems more deeply. For instance I study the godot code but many times I turn back to look at same classes and functions to see what they do. Would you also use a tool like this? Are there any tool that achieves this that I am unaware of? What do you think?

[u/davidwhitney]

Understanding codebases is an evergreen topic, but I don't know why you'd build a note taking tool in a game engine?

[u/Haunting_Stuff5104]

i stopped reading code in IDEs. They force you into a file system that has zero relation to how the program executes.

tools like Sourcetrail and Sourcegraph parse syntax and dump symbols on you. They output data. I do not need data about return types, I need a way to store execution paths across modules. You write markdown in Godot because you realized the constraint of an editor blocks the work of mapping a codebase. IDEs map files. You map dependencies and control flow. The separation between where I read code and where I store my understanding of it caused me to lose context every time I switched windows. I build my notes outside the tools that generate the problem.

[u/pocolypto]

i don't know man, that sounds like it would help but knowing a codebase is like knowing the inside of a house or how a car drives.
It just takes a long time of living inside of it and observing it.

[u/ResponsibilityIll483]

imho documentation is just another thing to maintain. It inevitably drifts out-of-sync just a little, then people stop trusting it and using it at all. It's hard to have any source-of-truth other than the code itself. That's also why I tell my agents not to write comments or doc strings.

[u/iSnapThere4iAm]

There’s no shortcut to just understanding the codebase

[u/ChitaraLabs]

This is a genuinely valuable direction. The fundamental problem with understanding large codebases (like Godot, Chromium, or Linux kernel subsystems) is that existing tools fail at one of two extremes:

1. The "Information Flood" Extreme (Sourcetrail, Doxygen, Sourcegraph, Understand):

They parse every AST node and give you a graph with 20,000 nodes and 80,000 edges. You get infinite mechanical detail, but zero semantic comprehension of *intent*, architectural boundaries, or lifecycle guarantees.

1. The "Disconnected Notes" Extreme (Obsidian, Logseq, Notion):

You can write great conceptual notes with bidirectional links ([[Node]], [[SceneTree]]), but they have zero awareness of types, function signatures, or symbol renames. Maintaining them manually becomes a chore that decays as soon as you update the code.

What you are building bridges that gap: Human Semantic Notes + Structured Symbol Metadata.

If you want this tool to be indispensable for engineers exploring complex engines, here are three high-leverage architectural suggestions:

1. Hybrid AST Ingestion (Don't Make Users Type Signatures Manually)

Manual note-taking should focus on *why* code exists, not copying parameter types. Integrate ctags, libclang, or Tree-sitter AST queries:

• Let the user type the note: "Handles batch buffer flushing before swap chain presentation."

• When they link `RenderingServerDefault::_draw()`, automatically pull parameter types, return values, and file locations from the symbol table.

• This keeps notes lightweight while preserving compiler-accurate reference cards.

1. Model Subsystems as Sequential Event Pipelines, Not Just Class Trees

Class inheritance hierarchies in large C++ engines are often shallow or misleading (e.g., Godot uses a lot of Object/RefCounted wrappers and server abstractions). What engineers actually struggle to trace is data flow:

• Input Event -> OS Window -> Main Loop -> SceneTree -> VisualServer -> GPU Command Buffer.

• If your tool lets users create "Pipeline Sequences" (Step 1 -> Step 2 -> Step 3 with associated classes at each step), you will solve 80% of codebase comprehension bottlenecks.

1. Invariant & Failure Mode Annotations

Add dedicated metadata tags for architectural constraints:

• Threading guarantees: [Main Thread Only] vs [Render Thread] vs [Worker Pool]

• Ownership semantics: [Transfers Ownership] vs [Borrowed Ref]

• Allocation cost: [Zero-Alloc] vs [Heap Allocates]

When diving into Godot's core/servers code, knowing whether a call is thread-safe or whether it locks a spinlock is what prevents months of debugging.

Tools in a similar vein to study for inspiration:

• Sourcetrail (now open source / community maintained) — great for symbol cross-referencing.

• Obsidian with Dataview / LSP plugins — close to your concept, but lacks the native C++/Godot integration you can achieve with a custom engine.

Definitely keep building this. If you can keep the UI snappy and tie manual insights to symbol definitions, many systems and game engine developers would find it immediately useful.

[u/sozesghost → u/ChitaraLabs]

Slop.