# Can (Should) I provide small feedback on provided code snippets, while also answering the question?

Question

When a user asks a question and provides a code sample, should I try to answer the question without changing his/her code too much, or can I also provide some small constructive feedback on the given code (if small enough / relevant) with an updated snippet.

Origin

I remember reading that SE is not meant for direct code feedback as that would make questions / answers very specific to a situation, but I do feel that some code feedback (like the example below) could increase someones knowledge.

I am talking about answering the question first and then have an extra note with something like 'As a hint, you could also achieve the same result with less code, making it more readable for yourself and others' and then providing a snippet with changes. (I am not talking about any personal aspects such as code conventions).

example: (C# Unity)

private void Update()
{
StartCoroutine("Changecolor", 3f);
}
IEnumerator Changecolor()
{
yield return new WaitForSeconds(3);
if(startstop == true)
{
int random = Random.Range(1, 4);
if (random == 1)
{
m_SpriteRenderer = GetComponent<SpriteRenderer>();
m_SpriteRenderer.color = Color.blue;
}
else if(random == 2)
{
m_SpriteRenderer = GetComponent<SpriteRenderer>();
m_SpriteRenderer.color = Color.red;
}
else if(random == 3)
{
m_SpriteRenderer = GetComponent<SpriteRenderer>();
m_SpriteRenderer.color = Color.green;
}
else
{
m_SpriteRenderer = GetComponent<SpriteRenderer>();
m_SpriteRenderer.color = Color.yellow;
}
}
}
private void OnMouseDown()
{
startstop = !startstop;
}


Which could be done with something like:

// store all colors in an array.
Color[] m_Colors = new Color[] { Color.blue, Color.red, Color.green, Color.yellow };

private void Update()
{
if (startstop)
{
StartCoroutine("Changecolor", 3f);
startstop = false;
}
}

IEnumerator Changecolor()
{
yield return new WaitForSeconds(3);

m_SpriteRenderer = GetComponent<SpriteRenderer>();

// select a random color from the array and apply it.
// Count() - 1 as arrays start counting at 0.
int random = Random.Range(0, m_Colors.Count() - 1);

m_SpriteRenderer.color = m_Colors[random];
}


The question I used as an example: changing color of sprite not every frame

final note: My first (and last) post on GDMeta has been a while ago, so if anything about my question is incorrect / wrong, please let me know.

I'd say, the question you can ask yourself is, will others benefit by the changes? It's not only OP that people are helping by answering, but future readers as well.

I saw this answer when it was posted, and I was really confused about what it is trying to do. I agree with you that it could use a lot of work to make it readable, but if the OP is new on C# and wouldn't understand the changes, they would just ignore them.

I've seen answers before addressing this in a way to satisfy both the OP and other readers. Simply answer the question, being as straightforward as possible without altering the code a lot. After that, you can have some extra information, something like "It would be better if you did X and Y in your code, as it makes it better because of reasons A and B".

This way, the OP can read the new information, and possibly benefit from them, or just focus on the solution, which might be more time-critical for them. But future readers can see both the solution and possible ways of making the code even better.

In this specific case however, I think your code might look too complex for OP. On that question I left a comment because I'm still not sure what OP is trying to achieve.

Keep in mind there's always the CodeReview StackExchange, for people looking to improve their code.

• So you suggest to not provide "more optimal" code, only "ways to make it better"? – Vaillancourt Oct 7 '19 at 14:05
• @AlexandreVaillancourt I think showing a completely refactored code would be close to being off-topic. But advice on how to make the code better can help everyone. – TomTsagk Oct 7 '19 at 14:16

My answer will go along the lines of TomTsagk, but will end differently:

1. provide the straight answer to their question;
2. add an horizontal line (blank line + ---);
3. tell them that you think of ways of making their code "more optimal";
4. describe what you think;
5. provide the code;
6. comment the code, explain what's going on.

Although they might not have a grasp of what you suggest now, your techniques and the code you use could get them intrigued and curious about new approaches.

• I like both answers, as they are mostly the same as what I was thinking when writing this question. Making people curious about new approaches is exactly one of the main reasons as to why I would give feedback on those code snippets. I did not know (/remember) about that horizontal line, but I like that idea. – D.Kallan Oct 7 '19 at 14:47

I've done this before, and typically the following applies:

• If the provided code is OK, barring that it might benefit from some refactoring, then I prefer to leave it be. The OP might be aware of this, or doing it this way for other reasons we don't immediately know about.
• The classic example of this in a Gamedev context might be someone who posts code using OpenGL immediate mode; a reply that focusses on "don't use immediate mode, use buffer objects", although correct and good advice, is probably actually not very helpful in terms of solving the problem.
• If there are other things obviously wrong with the code that would prevent the OP from achieving what they wish to do, then it would be a disservice to the OP to not at least point it out.
• It may be appropriate to encourage the OP to ask a bunch of extra questions about these hypothetical other wrong things, rather than going down too much of a rabbit hole in your answer to their original question.

Finally, one should always remember that one may not be seeing the actual code in a question. Remember that:

Questions about debugging a problem must provide a minimal, complete, verifiable example of the issue...

The code that is posted may therefore be this example, with idiomatic correctness perhaps being of lower priority than illustrating the problem.