Short answers and code-only answers

Question

What should we do with:

• Short answers (for example, "I suggest you use [hyperlink to this standard API] instead.")
• Code-only answers (for example, an improved version of the code in the OP)

Such answers could be improved (e.g. by adding an explanation of why the suggestion is helpful).

Is it required to improve these answers? If I can't easily edit one to improve it, should I:

• Leave it as is?
• Downvote it?
• Upvote it? (if the content is good though the format is lacking)
• Flag it, as "not an answer"?

N.B.: I don't really want to know just whether you "dislike" short answers; what I want to know is whether we should down-vote them, or, flag them.

• Downvotes: users may expect or accept down-votes without complaining: a down-vote is subjective, a matter of opinion; not really subject to dispute; and, just because you downvote something doesn't mean I ought to.
• Flagging: flagging is more serious, almost an insult, saying that the user doesn't have the right to say such a thing on this site. I don't want to flag short answers unless that's the accepted policy of this site.

Is it (or should it be) policy that short answers are unacceptable, and that regular users who know the site's policies therefore ought to know to flag them? If you flag an answer for this reason, should I agree and flag it too, or disagree and say that that this is an invalid flag?

Answer 1

I'd like to describe what I would like to see on this site, rather than the current practice.

As noted in Answering Guidelines (answer length), there is a desire for cultural change on this site. Allowing shorter answers should improve the answer rate by lowering the barrier to contribution, and hopefully increase reputation scores all around.

I think that the guideline for what passes muster as a short answer should be: Would this answer constitute a reasonable checkin log message?

Let's see how that rule would apply to various examples.

A code-only answer would be tantamount to committing code to a repository without a log message. Would you rewrite your colleague's code without stating a reason? I don't think that that would be acceptable in a professional context, and giving a code-only answer is analogous to committing new code just for the heck of it. Unless the code contains sufficient justification of the changes embedded in the comments, I don't think that code-only answers should be allowed. The justification doesn't have to be long, though. "You can shorten your code by using xyz" could be good enough for me, since "Shortened the code by using xyz" could be a commit log message.

In a recent answer, @AJMansfield wrote:

Here is a far and away superior solution: use java.util.Properties to handle your properties file.

That passes the test, in my opinion, because "Replaced configuration parser with a solution based on java.util.Properties" suffices as a commit log message. Some additional detail would have improved the answer, but the original answer was sufficient. Despite being just one sentence, it was amazingly insightful, enough to trigger a "Why didn't I think of that?" moment. I voted for that answer, and would do so again.

A second example of a short, valid answer by @Josay:

As far as I can understand

default: comment.replace(i, 0, "\\");

makes

case '\\': comment.replace(i, 0, "\\"); break;

useless.

The hypothetical commit log message would say: "Removed redundant case in a switch block." Indeed, removing the redundant line would result in an objective improvement, so that deserves to be an answer, not a comment.

How low can you go, hypothetically? I think that this could be a standalone answer:

If you put parentheses around your print statement, that is all it would take to make your program compatible with Python 3.

The reviewer presumably took the effort to verify Python 3 compatibility. The suggestion would result in an obvious improvement. (Obvious in retrospect.) It could work as a commit log message. That's good enough to be a standalone answer.

Conversely, a good guideline for what should be a comment is that comments should be treated as disposable. "Your code doesn't make sense at all" might be better as a comment, especially if you think that the original poster needs to fix the code in preparation for review.

Here's an example of a comment that should have been an answer instead:

Well, not really optimising, but for your four if ( *++s != '\0' ) conditions, if any but the last one fails, the loop will go off the end of the string and keep going - until it hits another \0.

Any remark that points out a bug in the program is too valuable to be a comment, and is worthy of receiving points. (Pointing out an outright compilation failure might be a gray area between answer, comment, and flag.)

Note that only short answers need to pass the commit log message test. There are other styles of critique for which the test doesn't make sense.

Also note that if you follow this reasoning, it should be acceptable for one user to post multiple answers to a question, as long as each answer stands on its own. Don't think of it as rep-whoring, think of it as the cultural change that this site needs if we're going to graduate.

Answer 2

In conclusion, after reading the other answers, I think that the consensus about flagging as "not an answer" is, more or less:

• Flag link-only answers; for example:

  There's an interesting implementation at http://example.com

• Do not flag short answers, even if they contains a link, provided that the answer would still be informative without the link; for example:

  It would be better to use java.util.Properties to handle your properties file.

• Flag code-only answers which bear little or no relation to the original code (e.g. a complete rewrite, which could have been written from scratch based on the problem description without reading the code in the OP)

• Do not flag code-only answers which are obviously based on and contain obvious improvements to the original code.

Instead of flagging you may:

• Downvote
• Post a comment to suggest improvement
• Edit to add context, reasoning, or simply a human-language introduction or lead-in.

Answer 3

Short answers (for example, "I suggest you use [hyperlink to this standard API] instead.")

Link-only answers I like not. These are (or at least has been, but I believe they are still) discouraged on StackOverflow and often converted to comments (I've flagged a bunch of these). Links can become obsolete, and what good would such an answer be then? Suggesting another API is fine, but should at least provide some real example for how to use it, in case the link go away.

Other short answers: It depends. Does the answer actually answer the question? Does the answer provide a way to greatly simplify the code in the question? If it does, then it might be a very good answer.

Code-only answers

This depends a bit on the question and a bit on the code in the answer. Generally, I don't like these. An important thing to ask yourself is: Is the code in this answer easily understandable, and is it obvious why this approach is preferred instead of the original? If it is both of this, then it's probably a good answer. Otherwise, you have some options: Down-vote and/or add a comment, possibly pointing them to this meta-question, saying that it'd be preferred if some things are added to the answer:

• What does the code in this answer do? / What is the difference between this code and the original code? (Explain the code! Don't just say something like "Can't you read?")
• Why is this a better approach?

The usage of flagging answers

If you flag an answer for some reason, it will be up to the ones who have the Moderation privilege. (Note that posts flagged with a custom reason are always handled by a moderator) Those with the privilege can agree or not with your flag, and may also add comments and/or down-vote answers.

You don't get punished in any way for having raised flags that eventually got rejected/disputed, so when in doubt: Use C4 You can always flag.

Answer 4

What I think of:

• Short answers (for example, "I suggest you use [hyperlink to this standard API] instead.")

  I find short answers with hyperlinks to be spammy. Some short answers are brilliant, upvote them. Most are lazy and not thought out, downvote them. Some answers should really be comments, those you can flag as not an answer.

• Code-only answers (for example, an improved version of the code in the OP)

  Yeah, I don't like those; I saw some old answers with the description of what is different in the comments, it just looks wrong in my mind. Too often code-only answers are 'this is what I do' or 'let me completely rewrite what you did and not give any explanation`. The funny part is that requests for extra explanation have in my experience never resulted into anything. To be frowned upon.

Answer 5

Consider this answer of mine. Let's ignore the first 4-line paragraph for now, as the bulk of that answer is all under the line. Scroll down to the bottom of that answer, and you'll find a 12-line code snippet that addresses one of the asker's primary concerns.

A code-only answer from me would have consisted only of this final snippet. This answer would be mostly completely useless. Would it improve the existing code? Sure. But it fails as an answer because it doesn't explain what the code does or how it works or why it's better than the existing code.

Moreover, everything in that snippet could easily be figured out by simply posting a link to the NSDateFormatter documentation.

The question is, does a code-only answer sufficiently explain to the asker why the proposed code is better so as to allow the asker to discern in the future when code A is better than code B and vice versa?

Code only answers shouldn't necessarily be flagged or closed as non-answers because they technically are an answer, but the absolutely should be downvoted!

This isn't StackOverflow where askers don't care about the quality of their code--only whether or not it works. This is CodeReview, where askers care about writing high quality code and code only answers don't do a good enough job of equipping the asker to write higher quality code in the future.

Answer 6

Consider @vnp's answer here. He only made 3 short points, one of which I rebuttled. Sure, he could have expanded the answer a bit to show me what he meant with example code of his own; but it's perfectly fine that he didn't because that isn't a requirement for answers.

Sometimes there is only so much you can improve without creating a whole new program.

Answer 7

I'd be inclined to accept code-only answers; but only if they're recognizably based on (an altered of) the code in the OP.

If you wanted to post a completely different implementation, you could do that as a comment with a hyperlink, not an answer.

If I see a code-only answer, it would be easy to add an introductory sentence.

I would:

• Upvote it if the code is good (and better than the OP)
• Downvote and comment if it's less good
• Flag it as not-an-answer if it's not based on the code in the OP

Answer 8

If it's a good library for that particular problem I'd upvote the answer. It's useful and could help the OP, so why shouldn't I upvote it? It usually isn't harmful, so I think it would be bad to downvote it.

On the other hand it could be boring to rewrite code n+1 times to use Multimap instead of Map<K, List<V>> or write a basic example as the official documentation already has. Reading these kind of answers could also be boring.

Finally, if the link was gone (and the library as well) the example also would be useless.

Code only answers also could be useful. The OP still can ask for clarification in comments. If it's helpful and/or provides a new approach I upvote. A code only answer still can be better than no answer at all.

Is it required to improve these answers?

I wouldn't do that. Write it as a new answer if the author doesn't improve their answer.