1.1.19 How to Comment Out a Line of Code

A Comment Can Temporarily Prevent a Statement from Executing

A single-line C# comment begins with:

//

You have already used it to write explanations.

The same syntax can temporarily turn one source line into comment text.

Original statement:

player1.team.name = "Wildcats";

Temporarily commented out:

// player1.team.name = "Wildcats";

The compiler no longer treats that line as an executable statement.

Commenting Out Is Useful for Investigation

Suppose one line throws an exception.

Temporarily commenting out the line can help answer:

Does execution continue past this point when this statement is not executed?

That can be useful diagnostic evidence.

It does not automatically prove that removing the line is the correct final solution.

Keep Temporary Investigation Separate From Final Code

Imagine the requirement says the program must assign the team name.

This line fails:

player1.team.name = "Wildcats";

Commenting it out:

// player1.team.name = "Wildcats";

may stop the exception.

The required team name is also no longer assigned.

The symptom disappeared because the behavior disappeared.

That is not the same as repairing the object relationship.

Use Commenting to Narrow the Problem

A careful diagnostic sequence can be:

1. Observe the failing statement.
2. Record the exception type and current state.
3. Temporarily comment out the suspect line.
4. Run again.
5. Observe what behavior changes.
6. Restore the statement before making the real correction unless the requirement says it should be removed.

The temporary change helps isolate behavior.

Comment Out One Focused Line

Avoid turning half of the program into comments.

If you disable many statements at once, it becomes difficult to know which one changed the result.

Use the smallest change that answers the current debugging question.

Preserve the Original Statement While Investigating

One advantage of:

// player1.team.name = "Wildcats";

is that the original source remains visible.

You can see exactly what was disabled.

That is safer than deleting the statement and trying to reconstruct it later from memory.

Do Not Leave Misleading Comments Behind

After the investigation, this is poor final code:

// player1.team.name = "Wildcats";  // crashes

if the requirement still expects the relationship and value to work.

The final source should reflect the actual intended solution.

Temporary debugging comments should not become unexplained permanent debris.

Commenting Out a Line Does Not Change Runtime State Directly

It prevents that statement from running.

Suppose:

player1.team = team1;
// player1.team.name = "Wildcats";

The first assignment still executes.

The second does not.

The final state reflects only the statements that actually ran.

This makes commenting useful when tracing which statement changes state.

Use the Technique With Evidence

A useful statement after testing is:

When I temporarily disabled this line, the exception no longer occurred, so this statement is part of the failing execution path. The debugger still showed that player1.team was null, so the relationship needs to be corrected rather than simply deleting the line.

That explanation is stronger than:

I commented things out until it worked.

Restore the Intended Program

Temporary commenting is a debugging tool.

The real goal is still to produce source that:

• represents the required UML;
• uses the intended objects;
• assigns the required references;
• runs the required behavior.

Use comments to investigate, not to hide unresolved defects.