Two ways to understand unfamiliar code
When you open a file you did not write, you are doing two separate things. You are working out its shape — how big, how deep, how many moving parts — and you are working out its intent, which is what it was trying to achieve and why.
Shape can be measured. Intent cannot, and anything that claims to tell you a function's purpose is inferring it from names and patterns, which is exactly how confident wrong answers get produced.
The [msm_tool slug="code-explainer"] keeps those apart. Offline it measures: line counts, nesting depth, longest line, indentation style, and function, class and method declarations found by pattern. Your code is never executed and nothing judges whether it is correct. With an AI key a model explains the logic instead, and is instructed to say when behaviour depends on code you have not pasted rather than inventing it.
What the measurements actually tell you
- Nesting depth is the most honest single number. Four levels of indentation inside one function usually means several responsibilities are tangled together, and it correlates with how hard the code is to change safely far better than length does.
- Code versus comment lines shows the documentation balance. Almost no comments in intricate logic is a warning. A very high comment ratio often means comments explaining what a line does rather than why, which rots the moment the line changes.
- Longest line flags the chained expression or the condition with five clauses in it. Those are where misreadings happen.
- Declaration count against total lines tells you whether you are looking at many small units or a few large ones.
- Indentation style matters when a file mixes tabs and spaces, which in some languages is a bug and in all of them is a diff that will fight you.
None of these is a verdict. A long, flat, well-named function can be perfectly clear, and a short deeply nested one can be dreadful. The numbers tell you where to look, not what you will find.
Reading a file you have never seen
- Find the entry points first. What calls into this? A route, a handler, an event, a command. Everything else is downstream of that.
- Read the signatures, skip the bodies. One pass over the declarations gives you the vocabulary before you try to follow any logic.
- Follow the data, not the control flow. Where does a value come in, what changes it, where does it get written or returned. Most bugs live on that path.
- Go to the deepest nesting. The most tangled block is usually where the real business rules were bolted on, and it is where the surprises are.
- Read the tests if there are any. Tests are the only documentation that fails when it becomes untrue.
The limits of explaining a snippet
A fragment cannot tell you what a fragment does. A function calling process(order) is opaque unless you know what process is, and no amount of analysis of the calling code will reveal it. This is not a tool limitation; it is what a snippet is.
The same applies to anything shaped by things outside the paste: framework conventions that make a bare method name meaningful, dependency injection, decorators, environment variables, database state, and side effects in code you did not include. A model asked to explain such a snippet may describe what it usually means in code like this, which is a reasonable guess presented in the same tone as a fact.
So paste complete units rather than fragments, include the imports, and set the language correctly — the same syntax means different things in different languages, and the pattern matching is language-aware.
Do not paste secrets
Real code carries credentials more often than people expect: connection strings, API keys, internal hostnames, S3 bucket names, staging URLs, customer identifiers in test fixtures. A comment naming an internal system is itself information.
Offline analysis runs entirely in your browser and nothing leaves the page. With an AI key it does leave — from your browser straight to the provider you chose, under their terms, which for free tiers often include using submitted text. Neither route passes through this site, and this site stores nothing, but the second route is a decision worth making deliberately.
Strip the values before pasting. Replacing a key with REDACTED costs nothing and changes no structural measurement.
Where explanations are most and least reliable
Most reliable on self-contained algorithmic code: a sort, a parser, a date calculation, a regular expression. The logic is entirely present and a good explanation of a dense regex saves genuine time.
Least reliable on framework glue, configuration and anything whose behaviour comes from convention rather than code on the screen. There the honest answer is often this depends on things you have not shown me, and an explanation that never says so is telling you less than it appears to.