0.2.26 How to Resolve Feedback System C# Code Errors

First Decide What Kind of Difference You Are Looking At

When feedback reports a problem in C# code, avoid changing the first statement that catches your eye.

Begin by identifying the kind of issue being described.

At this stage of the course, useful categories include:

• the wrong file or an outdated file was submitted;
• the required object was not created;
• the wrong type was used;
• a field assignment is missing;
• a value differs from the requirement;
• a required statement is in the wrong place;
• the source does not build;
• or a simple code-quality expectation is not being met.

Once you understand the category, you can inspect the correct part of the program.

Confirm the Submitted File First

If the feedback seems completely unrelated to what you see in Visual Studio, verify the file itself.

Ask:

• Did I save my changes?
• Did I build the current solution?
• Did I submit the requested file?
• Did I accidentally select an older copy?
• Am I looking at the same file that I submitted?

This simple check prevents a lot of unnecessary code editing.

Object-Creation Differences

Suppose the model requires one Player object:

player1 : Player

A corresponding introductory C# statement might be:

Player player1 = new Player();

If the source does not create the required object, compare the current statement with the model and requirement.

Common differences include:

• the object creation is absent;
• the wrong type appears after new;
• a second unintended object is created;
• or the expected name refers to a different object than intended.

Correct the specific object-creation difference rather than rewriting the entire method.

Field and Value Differences

Suppose the required state includes:

name = "Jordan"
jerseyNumber = 7

The C# source might contain:

player1.name = "Jordan";
player1.jerseyNumber = 17;

The object exists.

The field exists.

One value differs.

That is a much smaller problem than “the Player code is wrong.”

Change the evidence-supported value and leave unrelated working statements alone.

Missing Assignments

A new object may exist without all required scenario values.

For example:

Player player1 = new Player();
player1.name = "Jordan";

If the current requirement also needs a jersey number, the object is incomplete for that snapshot.

Return to the UML or specification and identify which required value has not been assigned.

The model helps you distinguish a missing state value from a missing object.

Build Problems and Requirement Problems Are Different

If the code does not build, the compiler is telling you that the current source cannot be translated successfully.

If the code builds but the Feedback System reports that a required value is wrong, the program may be syntactically valid while still failing the requirement.

Keep those questions separate:

Build evidence: Can the current source compile?

Requirement evidence: Does the current source represent or perform what the activity requires?

A successful build does not prove the second question.

Use the Debugger When Runtime State Is Relevant

If the source appears correct but the runtime object does not contain the expected value, use a breakpoint to inspect the actual object.

For example, if you expect:

player1.jerseyNumber = 7

pause after the assignment and inspect the Player object.

If the debugger shows 7, that supports your understanding of the runtime state.

If it shows something else, find the statement that actually produced or later changed the value.

This is more reliable than guessing from the final screen alone.

Correct One Evidence-Based Difference at a Time

A productive correction cycle is:

1. Read the current feedback.
2. Identify the exact requirement involved.
3. Locate the related source statement or submitted-file issue.
4. Make one focused change.
5. Save.
6. Build.
7. Submit again.
8. Read the new result.

If the feedback changes, that new message represents the current artifact.

Do not keep correcting an old message after the underlying issue has already changed.

Do Not Add Untaught Features to Fix a Simple Problem

At this stage, an object-creation problem should not require:

• constructors with parameters;
• properties;
• collections;
• inheritance;
• complex exception handling;
• or other later-course features.

If a correction seems to require a concept that has not been taught yet, return to the current requirement and supplied project.

There is usually a simpler correction within the current teaching boundary.

Treat Feedback as a Description of the Gap

The strongest goal is not:

Make the system accept my submission.

It is:

Understand how the submitted code differs from the required program state and make a focused correction.

That habit becomes increasingly important as programs grow larger and the feedback becomes more complex.