Code Explainer

In short Explaining code means saying what it does, why it is arranged that way, and what the names do not tell you. That third part is where the value is: variable names describe intent at best, and the parts that need explaining are usually the ones with no name at all — why a value is checked before use, what an early return is guarding against, why an operation is wrapped in a retry. Reading unfamiliar code is easier with a fixed order: find the entry point, follow the data rather than the lines, identify what the function returns, and only then read the details in between. The parts worth pausing on are error handling, which usually documents what has actually gone wrong in production, and any comment explaining a decision, which is the one kind of comment that does not go stale. Two caveats about any explanation, generated or human. It describes what the code appears to do, not what it does in every case at runtime. And it cannot know your codebase's conventions, so it will explain an idiom as if it were novel.