Static analysis vs. dynamic analysis
These are the two fundamentally different ways to find problems in a codebase. One reads the code. The other runs it. Most real engineering workflows use both, because each one is blind to exactly the kind of problem the other one is good at catching.
What static analysis does
Static analysis examines source code without executing it. A tool tokenizes and parses the text, then checks it against rules and metrics: is this function too long, is this catch block empty, how many independent paths run through this branch. Nothing ever runs — there's no build step, no test harness, no runtime environment required. That's also why it's fast: REPO-SIGHT can return a full report on a repository in seconds, because it never compiles or executes a single line of the code it's reading.
What dynamic analysis does
Dynamic analysis runs the program and observes what actually happens. Unit tests are the most familiar form. So are memory sanitizers (AddressSanitizer, Valgrind), profilers that watch real CPU/memory usage, and fuzzers that throw thousands of malformed inputs at a program to see what makes it crash. Dynamic analysis can only tell you about the paths that were actually exercised during the run — it has no opinion about code that was never called.
What each one misses
- Static analysis can't tell you if the output is correct. It can tell you a function has 8 branches and no comments. It cannot tell you whether the function computes the right answer — that requires actually running it against known inputs.
- Dynamic analysis can't see code it never touches. A test suite with 60% coverage tells you nothing about the other 40%. A race condition that only appears under specific timing won't show up if the test that would trigger it never ran.
- Static analysis catches structural rot early; dynamic analysis catches behavioral bugs late. A cyclomatic complexity of 30 is visible the moment the function is written. The bug it eventually causes might not surface until a specific input hits production months later.
They're complementary, not competing
A healthy pipeline typically runs static analysis first — fast, cheap, no build required — as an early gate before code even gets to tests. Dynamic tools (unit tests, integration tests, sanitizers) run afterward, closer to merge or deploy, because they're slower and need a working build. Neither replaces the other: a codebase can have 100% test coverage and still be an unmaintainable tangle of 400-line functions, and a codebase can have a perfect static-analysis grade and still have a logic bug that only a test would catch.
Where REPO-SIGHT sits
REPO-SIGHT is a static analysis tool, deliberately. It tokenizes and parses your C++, Python, or Java source and never executes, builds, or installs anything from the repository it's given — that's both a speed decision (no build step means a scan finishes in seconds) and a security one (no arbitrary code from a random public GitHub repo ever runs). If you want the dynamic side of the picture — does the code actually work — that's still on your test suite, not on any static tool, REPO-SIGHT included.