Offline wird Ihr Ausschnitt vermessen, nicht gelesen. Gezählt werden Gesamt-, Code-, Kommentar- und Leerzeilen, die tiefste Verschachtelungsebene wird ermittelt, die längste Zeile gefunden, festgestellt, ob Sie mit Tabs oder Leerzeichen einrücken, und Funktions-, Klassen- und Methodendeklarationen werden über Muster erkannt. Das ist lexikalische Analyse: Ihr Code wird nie ausgeführt, und nichts davon beurteilt, ob er korrekt ist.
Mit einem kostenlosen KI-Schlüssel erklärt ein Sprachmodell stattdessen die Logik — was der Code insgesamt tut, wofür jeder wesentliche Teil da ist und was sich am Ausschnitt allein nicht erkennen lässt. Es ist angewiesen zu sagen, wenn das Verhalten von Code abhängt, den Sie nicht eingefügt haben, statt darüber zu spekulieren.
So bekommen Sie eine brauchbare Erklärung
-
Vollständige Einheiten einfügen:
eine ganze Funktion lässt sich weit besser erklären als ein Bruchstück davon. Schneiden Sie an Funktionsgrenzen, nicht nach Zeilenzahl.
-
Die Importe mitgeben:
der Kopf einer Datei bestimmt oft, was der Rest des Codes tatsächlich tut.
-
Die Sprache richtig einstellen:
Deklarationsmuster und Kommentarsyntax unterscheiden sich je Sprache, eine falsche Einstellung ergibt falsche Zeilenzahlen.
-
Keine Geheimnisse einfügen:
mit Schlüssel geht Ihr Code an den gewählten Anbieter. Entfernen Sie vorher API-Schlüssel, Tokens, Passwörter und Verbindungszeichenfolgen.
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.