How to Talk About Code in English

to declare

To introduce a variable, constant, function, or class for the first time.

“We declare a constant at the top so the value is easy to change later.”

to initialize

To set an initial value for a variable, or to set up an object so it is ready to use.

“The constructor initializes the database connection and sets the default timeout.”

to call / invoke

To execute a function or method.

“This middleware is called on every request before it reaches the route handler.”

to pass

To provide a value as an argument to a function.

“We pass the user ID and the token as separate parameters so the function stays testable.”

to return

To send a value back from a function to the code that called it.

“If validation fails, the function returns early with an error object.”

to iterate / loop through

To go through a collection of items one by one.

“We iterate over the list of events and filter out anything older than 30 days.”

to check / validate

To verify that a condition is true or that a value meets certain requirements.

“Before inserting the record, we check whether a row with that email already exists.”

to handle

To deal with an event, error, or edge case explicitly in the code.

“This catch block handles the case where the external API is unreachable.”

to throw

To raise an exception, stopping normal execution and passing control to an error handler.

“We throw a custom exception here so the caller knows exactly what went wrong.”

to parse

To read and interpret structured data, such as JSON, XML, or a string, and convert it into a usable format.

“We parse the response body and map it to our internal User type.”

to instantiate

To create a new instance of a class.

“We instantiate a new HTTP client on startup and reuse it across requests.”

to extend / inherit from

To create a class that builds on top of another, inheriting its behavior.

“This class extends the base repository and adds pagination support.”

to implement

To provide the actual code for an interface, abstract class, or function signature.

“The PaymentService class implements the IPaymentProvider interface.”

to override

To replace a method from a parent class with a new version in a child class.

“We override the default serialize method to exclude the password field from the output.”

to expose

To make a function, variable, or endpoint available to other parts of the code or to the outside world.

“This module exposes a single function — everything else is kept private.”

This [function / method / class] [verb] ...

When to use it

The most natural way to start any code explanation. Pick a verb from the list above.

“This function takes a list of user IDs and returns the ones with an active subscription.”

It takes [X] and returns [Y].

When to use it

Describing a function's inputs and outputs. Useful at the start of a walkthrough.

“It takes a raw JSON string and returns a validated user object, or null if parsing fails.”

First, ... Then, ... Finally, ...

When to use it

Walking through a sequence of steps in order.

“First, we validate the request body. Then, we check the database for duplicates. Finally, we insert the record and return the new ID.”

If [condition], [consequence].

When to use it

Explaining conditional logic or edge cases.

“If the token is expired, we redirect the user to the login page instead of returning a 401.”

The reason we [did X] is [because / so that] ...

When to use it

Explaining a design decision or a non-obvious choice in the code.

“The reason we cache the result here is so that repeated calls within the same request don't hit the database.”

This is where [X] happens.

When to use it

Pointing to a specific line or block during a live walkthrough or code review.

“This is where the token gets attached to the request headers before it's sent to the API.”

We use [X] here instead of [Y] because ...

When to use it

Explaining a technical trade-off or why an alternative was not chosen.

“We use a map here instead of a list because lookups need to be constant time.”

This could break if ...

When to use it

Flagging a risk, edge case, or assumption in the code.

“This could break if the API returns a null value for the user field — we should add a guard here.”

“Let me walk you through this.”

When to use it

Opening a code explanation, a screen share, or a demo.

“Let me walk you through how the authentication flow works from the moment the user submits the form.”

“Starting from the top ...”

When to use it

Beginning a top-to-bottom walkthrough of a file or function.

“Starting from the top: we import the dependencies, then we define the schema, then we export the handler.”

“If you look at line [N] ...”

When to use it

Directing attention to a specific part of the code.

“If you look at line 42, that's where we set the default timeout — it's currently 5 seconds.”

“The happy path is ...”

When to use it

Explaining what happens when everything works as expected, before covering error cases.

“The happy path is: request comes in, token is valid, data is fetched, response is returned. The error handling is further down.”

“The tricky part here is ...”

When to use it

Flagging a section of code that is complex, counterintuitive, or easy to get wrong.

“The tricky part here is the order of operations. The cleanup function runs before the callback, which is not obvious.”

“I left a comment explaining ...”

When to use it

Referring to inline comments in the code during a review or walkthrough.

“I left a comment explaining why we do the null check before the loop — the API can return undefined in some cases.”

“Does this make sense so far?”

When to use it

Pausing during an explanation to check understanding.

“So the middleware runs before every request and attaches the user object to the context. Does this make sense so far?”

“Any questions about this part?”

When to use it

Inviting questions after explaining a specific section.

“That covers the data layer. Any questions about this part before I move on to the API routes?”

“I'll skip over [X] for now — the important thing is ...”

When to use it

Keeping a walkthrough focused by deferring less relevant details.

“I'll skip over the error handling for now — the important thing is to understand the main data flow.”

“This is a bit of a workaround because ...”

When to use it

Acknowledging that the code is not ideal and explaining the constraint that led to it.

“This is a bit of a workaround because the third-party library doesn't support async callbacks in this version.”