The Comment That Wasn’t Just a Comment

A %> inside a comment at the top of a Classic ASP include file ended the server code early, even though the comment was only showing an example of how to use the file. The file looks for its <% and %> boundaries before it decides what is a comment, so the closing marker in my example was read as a real boundary and the file could be split in the wrong place. I 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.

The file was written for Classic ASP, 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. I had copied both into the example so a reader could see the whole shape of the code.

That was the problem.

At first, I left the example exactly as it was. A comment should protect it, I 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 I 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.

In this case, 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 not being clever or careless. It was following its own order of operations. First, it found the outer boundaries. Only afterward could it understand the language inside those boundaries, including comments.

A kitchen-table comparison helped me 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 page could see the closing marker too early and split the file in the wrong place. I did not need to wait for a page to go live to learn that lesson. The file never reached the main branch with that example in it.

The first attempt did not work because it treated a comment as a shield when this particular kind of file looked for its boundaries before it looked for comments. The cost was not a customer problem or an outage. It 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.

I 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 is better than 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.

This was not a lesson that 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 not the words themselves. It is the order in which a system notices them.

The fix was small: the header now says to include the file and then call the check, and the <% and %> that used to wrap the example are gone. That is the whole repair, and it exists because %> was read as the end of the server code before anyone, or anything, got to the fact that it sat inside a comment. A comment only protects what the file has already agreed to read as a comment, and this file found its boundaries first. So 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/blog/2026-04-10_comment-that-wasn-t-just-a-comment
WHAT HAPPENED: A Classic ASP header comment included 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.