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, "\\");
case '\\': comment.replace(i, 0, "\\"); break;
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.