What Is a CL in Software Engineering?

In software engineering, CL is short for changelist: one self-contained set of code changes sent for review. It is the unit that a reviewer reads and approves.

The term comes from Google, which uses CL the way most GitHub users say pull request. Perforce, the version control system, uses the same word for a group of files submitted together.

A CL has one purpose. It should add one feature, fix one bug, or do one cleanup, and nothing else.

What a CL contains

The description is read far more often than the code. It ends up in the commit history, where future engineers use it to find out why a line exists.

CL, PR, MR and diff mean the same thing

Different companies and tools use different words for the same unit of review.

If a job description or an interviewer says CL, read it as pull request. The review steps are the same.

The life of a CL

1. You write the change on your own branch or client.
2. You send it for review with a description and the tests.
3. Reviewers leave comments, and you answer each one.
4. A reviewer approves it.
5. Automated tests run, and the change is merged into the main branch.

How big should a CL be

Small. Google's public code review guide describes about 100 lines as a reasonable size and around 1,000 lines as too large.

The reason is measurable. A reviewer reading 100 lines finds real problems. The same reviewer reading 1,000 lines approves it and finds almost nothing.

Split large work into a sequence of CLs. Refactor in one, add the feature in the next, then update the callers.

What reviewers check

• Correctness. Does it do what the description says, including the error paths.
• Tests. Is there a test that fails without the change.
• Design. Does it fit the existing structure, or work against it.
• Naming and clarity. Can a new engineer read it in a year.
• Scope. Does it contain anything unrelated to the stated purpose.

Reply to every comment, even if the reply is one word. An unanswered comment stalls the CL.

Other meanings of CL

The letters are used elsewhere in computing, so check the context first.

In an engineering conversation about review, changelist is almost always the right reading.

How to Prepare

• Write the description first. One line of summary, then the reason. Do it before you open the code.
• Keep each change to one purpose. If you cannot describe it in one sentence, split it into two changes.
• Learn the reviewer side. Best practice for code review and the golden rule of code review cover what strong reviewers do.
• Use a checklist until it is a habit. See a code review checklist and the principle of code review.
• Practice the code that gets reviewed. Grokking the Coding Interview trains the clear, small solutions that pass review quickly.
• Explain your choices out loud. A mock interview builds the same skill that answering review comments needs.