The Closing Marker Inside a Comment That the Server Treated as Real

A %> inside a comment at the top of an include file ended the server code early, even though the comment was only showing an example of how to use the file. The file belongs to an older web application that marks its server code with <% and %>. It looks for those boundaries before it decides what is a comment, so the closing marker in our example was read as a real boundary and the file could be split in the wrong place.

We had pasted the full example, wrapper included, into the header to make the instructions easier to follow. It looked harmless, and a comment is supposed to protect whatever it holds.

What the file actually does first

The file was written for an older way of building web pages. It uses four small punctuation marks to show where server instructions begin and end: <% at one end and %> at the other. We had copied both into the example so a reader could see the whole shape of the code.

At first, we left the example exactly as it was. A comment should protect it, we thought. That is what a comment is for. It is like writing a note in the margin of a recipe. The recipe reader should ignore the note and keep following the steps.

But this file did not read the note in the order we expected. Before it could understand that the text was a comment, it first looked for those four punctuation marks. The scary word for them is a delimiter. It simply means a marker that tells a system where one section stops and another begins.

So the closing marker, %>, could tell the file that the server instructions were over, even though a person could plainly see it was only an example in a comment. The system was following its own order of operations. First it found the outer boundaries. Only afterward could it understand the language inside them, including comments.

A kitchen-table comparison helped us keep the order straight. Imagine a paper form that gets cut into sections along heavy printed lines before anyone reads the handwritten notes on it. If a handwritten note happens to contain something that looks like one of those heavy lines, the cutter does not pause to ask what the writer meant. It cuts first. The note gets read later, if it is still in the right section.

That is why putting the full example inside the comment was not safe. The file never reached the main branch with that example in it, so we did not have to wait for a page to go live to find this out.

What it cost

There was no customer problem and no outage. The cost was the time to stop, understand the order in which the file was read, and rewrite the instructions before the file could be used. It also cost a little convenience. A reader no longer gets a complete block that can be copied and pasted.

We changed the header to describe the important part instead. It says to include the file and then shows the call that checks whether a named feature is enabled. The surrounding <% and %> were removed from the example. The reader can still see what to do. They just do not see the exact wrapper that could confuse the file.

That trade was worth making. A shorter, less copyable instruction beats a neat-looking example that carries a hidden risk. When the full syntax needs to be shown, it belongs in documentation outside the processed file, where the punctuation can be read as ordinary text.

Ask what gets read first

Not every website tool behaves the same way. Different systems use different markers and different rules. The useful habit is simpler: when a file is handled by more than one layer, do not assume a comment protects every character inside it. Ask what gets read first.

That question matters outside programming, too. A note on a form, a label on a box, or a special character in a spreadsheet can be treated differently from what a person intended. The problem is often the order in which a system notices them.

A comment only protects what the file has already agreed to read as a comment, and this file found its boundaries first. The example in that header is now a little less copyable, and the file never has to guess where its code ends.

dxdev LESSON · paste into your AI coding agent
LESSON: A comment in a parsed file isn't safe from the parser just because it's a comment
SOURCE: dxdev.com/everyday-ai/comment-that-wasn-t-just-a-comment
WHAT HAPPENED: A header comment in an older web application's include file contained a full code example using the language's own server-code delimiters, <% and %>, for illustration. The parser scans for those delimiters before it recognizes comments, so the closing delimiter inside the example comment could tell the file that server instructions had ended, splitting the file in the wrong place even though a person could plainly see the text was just an example. The fix removed the delimiters from the example and described the usage in plain text instead, moving any full syntax example to documentation outside the processed file.
THE RULE: When a file is processed by more than one layer, delimiter scanning first, then comment or language parsing, a comment does not protect every character inside it. Check what gets read first before assuming a comment is a safe container for example syntax.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any comment block containing the file's own language delimiters, such as <% %>, { }, or nested templating markers, used purely as a documentation example.
  2. Any header or docstring example that could be copy-pasted verbatim and accidentally executed or misparsed rather than read as illustrative text.
  3. Any other processed file type in the codebase, a templating engine or preprocessor macro, where comments are assumed inert but the delimiter scan happens before comment recognition.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.