What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 134 Stack Exchange communities.

There have been several discussions regarding code-only answers (answers that contain only code blocks with no textual explanation whatsoever):

Personally, I can't see why the quality filter should let such answers through at all. The main problem I have with code-only answers, especially once they're flagged as not an answer or very low quality, is that we can't determine at a glance whether these answers are:

  • Genuinely attempting to answer the question
  • FGITW/SCITE answers
  • Trying to correct an error in the question without actually answering it
  • Random code dumps that may or may not relate to the question even by programming language or keyword(s) in the question

In particular, what exactly is an "informative code-only answer"? Does it mean the code is self-documenting? Does it mean the code substitutes code comments for a proper write-up? This is all very fuzzy. From the response by Nicol Bolas to the last question above:

I have never seen a code-only answer that couldn't be made better with the addition of appropriate text. They are of lower-quality than the same answer with some text.

This text makes all the difference, IMO, between an answer and a non-answer. Without it, it's often needlessly difficult to tell.

Existing code-only answers that are good-faith attempts to answer the question should be edited or downvoted, yes. But if the quality filter already tries to block code-only questions, why not block code-only answers too? These answers are often low quality, and (almost) always have ample room for improvement, just like questions.

share|improve this question
3  
"This text makes all the difference, IMO"... I agree completely. Although I think a filter could easily be worked around by added some useless text as well as the code (e.g. "Try this"). Here's an example from earlier today. Several answers with code and a tiny bit of text which isn't helpful whatsoever. –  James Allardice Sep 25 '12 at 10:44
    
@James Allardice: That's true. This behavior is already being observed in questions: I just had to edit a question that used the quality filter message as text padding. But some people will try to work around quality filters anyway, and I think "Try this" is alright as it at least says something about the code (e.g. "I'm not 100% certain but could you see if this works for you?"). What I would consider really worthless is something like "here's the code", or even gibberish. –  BoltClock's a Unicorn Sep 25 '12 at 10:46
1  
If the text in an answer doesn't help to explain the code, it'll probably be downvoted or edited anyway. Just because one can circumvent the quality filter doesn't mean it's OK to do so. –  BoltClock's a Unicorn Sep 25 '12 at 10:51
1  
"Existing code-only answers that are good-faith attempts to answer the question should be downvoted in hopes that they'll be improved, yes." I completely disagree. For example, the code could be commented, also, the downvoter may not be familiar with the language. –  Remou Sep 25 '12 at 11:24
    
@Remou: Yeah, good point. I've edited it. –  BoltClock's a Unicorn Sep 25 '12 at 11:26
    
Is there a way to search for the highest-upvoted code-only answers on StackOverflow? Whether or not you agree with the premise of this post, seeing a collection of what the community has deemed to be good code-only answers (some of which are bound to be one-liners with >100 upvotes) would be highly interesting and relevant. –  Mark Amery Sep 13 '13 at 18:25
    
@hayd: casperOne's answer echoes my thoughts exactly. –  Robert Harvey Sep 13 '13 at 19:55

3 Answers 3

Code-only answers fall under "Very Low Quality" for me and are candidates for deletion*.

This extends from my belief that "self-documenting code" is a myth. Code can only tell you the how, it doesn't tell you the why. That's what you need comments for.

On Stack Exchange, the how is important, but a great part of the level of quality comes from the fact that people go to great lengths to explain the why (have you seen an Eric Lippert answer lately? No. I'll wait *muzak plays*).

These answers can always be improved.

While a code-only answer get the person who asked the question past whatever hurdle they might be facing, it doesn't do them or future visitors much good in the long run.

We've always touted that we aren't a code factory. We are the people who teach others to fish. Code-only answers only feed a person for a day.

*(Of course make sure to see if there are other answers that sufficiently answer the question that are better, etc.)

share|improve this answer
4  
As Remou mentioned, "how" could be in comments, which, in my opinion often allows for more natural explanation. Such a filter would still treat this as poor answer, until you pull out all structured comments and lump them into single wall of text outside of code. –  Oleg V. Volkov Sep 25 '12 at 12:11
    
@OlegV.Volkov They could be put in comments, but in practice, it's not done a lot, if at all on Stack Overflow. I'm not saying comments in code can't do this on Stack Overflow, but you're really placing the onus on the person reading the answer, and we'd like to reduce that. –  casperOne Sep 25 '12 at 12:14
2  
I don't see how it is inconveniences people seeking answer, on contrary, I think this potentially makes code in answer easier to understand. If under "person reading the answer" you mean reviewers, then I must say that IMO reviewer convenience must absolutely never be prioritized over people who want answers. –  Oleg V. Volkov Sep 25 '12 at 12:20
3  
@OlegV.Volkov I disagree completely. If we're only targeting the person asking the question, then we've failed. The point is to be a lasting resource. If everyone that comes after with the same problem has to dig through the code to gain understanding when a short synopsis could be provided, then so much the better. Additionally, by giving a short synopsis, it better helps open the answer up to critique, leading to an even better refinement of the answer. Burying this information in the code just makes it more difficult for everyone that's going to process it after. –  casperOne Sep 25 '12 at 12:24
1  
I find it interesting that when someone says that SO is about answers, the response is that it is about the future and when someone says it is about the future the response is that it is about answers, to quote Oded in response to "As I understand it, Stack Overflow is about the future" No. Stack Overflow is about helping programmers - now., which response was heavily voted up. –  Remou Sep 25 '12 at 13:19
1  
@Remou From your perspective it's about helping programmers (you, or someone else) now. But that's a narrow view. There's the larger issue of what is good for the health of the site. That view is what makes Stack Overflow the go-to source of information for programmers. Oded is right, IMO. –  casperOne Sep 25 '12 at 13:25
1  
@Remou Additionally as people curating the content that we hope will be around for a long time, our primary concern is quality over immediacy. If it takes someone fifteen extra minutes to flesh out an answer into something that can stand for years, then you should always do that. Fifteen extra minutes, IMO, falls squarely within the definition of now. We're not even talking about a span of days here, we're talking minutes, hours at most. That time cost is purely acceptable when taking into account the greater concerns of the site. –  casperOne Sep 25 '12 at 13:27
    
You say that "I disagree completely. If we're only targeting the person asking the question, then we've failed." and you also agree "No. Stack Overflow is about helping programmers - now" I do not see how these two views are so easily reconciled. One or the other must take priority. A person answering may not have an additional 15 minutes and a code only answer may save the questioner several hours. Thus the programmer is helped and helped now. –  Remou Sep 25 '12 at 13:31
3  
@Remou If one doesn't have the time to write a quality answer, they shouldn't be writing an answer. A code-only answer is not a quality answer, therefore, they shouldn't be providing it. It's the same as a code-only question. If one can't be bothered to put the effort into describing their problem, then the site is not a good fit for them. –  casperOne Sep 25 '12 at 13:40
    
In that case, if only quality answers are acceptable, where does "No. Stack Overflow is about helping programmers - now" come in? –  Remou Sep 25 '12 at 13:46
3  
Yes, it does. My initial argument was that there are two widely different opinions on answering questions, both of which are strongly supported, which can be quite confusing. Meta is getting more and more like a religious text where you can find a quote to match any opinion. –  Remou Sep 25 '12 at 14:08
3  
If anyone has an opposing view, post it as a separate answer and let's not have this answer soapbox to your sudsy desires. Again. –  random Sep 25 '12 at 14:30
1  
@casperOne, don't you think that different people have different things easy to understand? Why you project your own personal view of "only synopsis is easy to understand" on each and every reader? I'm fine with community up/downvoting to arguably objectively mark an answer as "good". I'm absolutely not fine about enforcing policy liked by some specific moderators. –  Oleg V. Volkov Sep 25 '12 at 18:19
4  
@OlegV.Volkov Who's enforcing policy? casperOne posted an answer presenting his opinion on the issue, drawing from personal experience. If you disagree with it, or have different experiences to share, post an opposing answer and let the community decide which one we favour. –  Yannis Sep 25 '12 at 18:44
5  
+1 - We've always touted that we aren't a code factory. Could not agree more with that statement. –  Travis J Sep 13 '13 at 17:38

I believe that this is a result of the goto scapegoat on meta, the fastest gun in the west problem.

Code only answers are typically posted to questions which are on the cusp of being on topic. These questions are easily answered with one or two lines of code as an answer.

In order to try to answer that question quickly, users will post the correct code to fix the situation as fast as possible. Once posted, they will then edit in comments, suggestions, links, and explanations - or at least they intend do.

However, once the OP accepts an answer, answers which did not receive improving edits tend to become abandoned. I can see how looking back it may seem that these posts were done with utter disregard, but the fact is that the OP found their solution and so the other interested parties moved on.

long term view

Flagging an old answer which is solely comprised of code as "Not an answer" seems like it would appropriate, but only if the code is truly not helpful. If there is no uniqueness to the code with regards to other answers then by all means flag it.

That being said, I think that downvoting these answers is appropriate. It encourages the answerer to review their answer.

Best case scenario is that if you understand the code and context, and it is of that much importance, then you edit in an explanation for the code and upvote it if that edit made it a clear unique answer to the question with a clear solution.

Keep in mind that the guideline for taking action against answers does not include code only answers, "Answers that do not fundamentally answer the question may be removed. This includes answers that are:

  • commentary on the question or other answers
  • asking another, different question
  • “thanks!” or “me too!” responses
  • exact duplicates of other answers
  • barely more than a link to an external site
  • not even a partial answer to the actual question

If you wish to improve an existing answer, click the edit link beneath it." -Why and how are some answers deleted?

short term view

Filtering code only answers will only slow down the response time of answerers, and may result in the use of workardounds such as gibberish or placeholders.

For example


Do this:

$("#place").append("<blink>Hello World</blink>");
share|improve this answer
    
interesting - these quick-draw, short-code answers likely far outnumber the longer, but code-only answers (?) Seems to me that if someone goes to the effort of posting a longer answer, they would at least comment to some degree. –  Howard Pautz Sep 13 '13 at 17:59
    
@HowardPautz - I think that the intent isn't to leave just a few lines of code at first. But once the attention has left the question then people answering tend to leave as well. I made an edit to my answer; I believe that if you come across these types of answers down the line, actions can still be taken. I still do not think there is a good preemptive way to handle these code only answers. –  Travis J Sep 13 '13 at 19:09
    
agreed +1 for your edit's good clarification. Yes, the ssmall-code blob answers do seem to be short lived, but stay around like unusable rubble - often annoying in fact, if you're researching a related problem, because it takes longer to put the chunks into context. Maybe this is part of what Boltcock was concerned about. Agreed about not much to be done about pre-emptive. I wonder if this is an instance of where editing an answer by adding more information would be a good thing. E.g. I came across a post that fit the problem I was working on, but I knew that (cont...) –  Howard Pautz Sep 13 '13 at 19:29
    
(... cont.) other readers might not understand what was up - so I added comments to the code, instead of flagging it as being poor. Do you think this is a good practice (assuming the 'editor' has time to do so, of course.) –  Howard Pautz Sep 13 '13 at 19:30
    
@HowardPautz - Me personally, I think that editing in context is useful and usually appreciated. If improvement is an option then I think it would help a lot of other users for those improvements to be made in an edit. In my opinion it is also important not to be too hasty, and let the original answerer make the edits if they are going to - which is to say it is probably best to address older answers before newer ones. –  Travis J Sep 13 '13 at 19:46
    
@ TravisJ OK, very good - when I encounter such posts, the OP and people who might have been interested in answering have, as you say, left already. So I think of it like this: if I were to find this post, what would I need to know? And then edit / add in info accordingly. (Ironically one time I did this, the answer I edited got a new down vote within an hour, then went back up again a bit higher --- no accounting for editorial taste, I guess :)) –  Howard Pautz Sep 13 '13 at 19:52

Can we objectify this more by considering all the permutations of code and comments possible and review from there? As programmers, recall all the variations we see in working code and in text books.

Clearly the pros and cons of each variant below have been debated for years. Yet, IMO there is a common consensus applicable --- it should be possible to agree on which posting style is "best" or at least preferable here, right ? From that, we should be able to get a workable approach to Boltcock's OP.

A question can be formulated so:

  1. Comment only

  2. Code only

  3. Block comments before code sections (with little or no on-the-code-line comments)

  4. Code with embedded / on-the-line comments

  5. Both block and embedded commenting mixed into the code (items 3 & 4 )

I ask you now to put on your "code maintainer's" hat, and imagine you have to pick up where someone else left off in project - say a year later. (It could even be your own project!) And, is often the case, you are only slightly familiar with the project.

Which one would you prefer to deal with ?

Clearly, #1 is generally insufficient here and is frequently rejected in its many forms.

From a code maintenance standpoint, the further down that list you go, the easier the code is to work with - for you and others who follow. Code maintainability (due to clarity that is, not internal workings) is directly parallel with would make a good question.

share|improve this answer
    
I'm not really sure what you're advocating with this answer. Personally I disagree when I see explanation of what the code does hidden as inline comments (both on SO and in real life). –  hayd Sep 16 '13 at 22:20
    
@hayd I'm advocating the we need to decide what balance needs to be there between code and comments - this is what underlies Boltcock's question, does it not ? (I'm not taking a stance re code vs. comment, other than that more comments is usually better than less.) Does that make sense ? –  Howard Pautz Sep 17 '13 at 0:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .