14

Should editors be changing code in questions (excluding formatting to make a code block)?

I saw two recent cases, linked below, where the code that was originally posted had been changed. In both cases curly brackets { } were replaced by round ones ( ). If the original author simply pasted the code into the question, then the curly brackets may have been the cause of any problems, or at least contributed to them.

Instead, shouldn't the editors make a comment or post an answer that says "replace the curly brackets with round ones" (in addition to any other suggestions/solutions) instead of changing the code?

https://gis.stackexchange.com/posts/63751/revisions

https://gis.stackexchange.com/posts/63816/revisions

Edit: One of the reviewers of the suggested edit (the first link) agrees, but was over-ridden. That reviewer makes a good point that future readers may be confused since they don't see the original error in the question. https://gis.stackexchange.com/review/suggested-edits/15488

1
  • It's been a full day and there has been no disagreement with this. Considering that, I'm going to undo the edits that were made to the code in those questions, but retain the valid edits the original posters made to further clarify their questions. Any objections?
    – user3461
    Jun 19, 2013 at 19:55

3 Answers 3

Reset to default
19

I strongly agree: changes to code in questions should be limited to formatting it as code (adding a few spaces of indentation using the Preformatted text tool), nothing more. Readers who think such code should be changed need to request those changes within comments: that's what the comment facility is for.

The issue is more delicate for answers: often, proposals to edit code in answers are intended to fix small typographical errors. My policy is that unless I am an expert in that language and platform and understand exactly what it is intended to do and doing, I will not approve the review: I will skip it and leave the approval for someone else. When I am not an expert (which is most of the time) but can plainly see that the proposed edit is extensive (I have seen wholesale changes in code attempted by new readers), I will reject it.

There is no shame in skipping a task you are not qualified to do (and much damage that can be created by undertaking such tasks). Reviewers are not obliged to act on everything that is presented to them!

4
  • I confess that to improve readability I sometimes eliminate blank lines from code in questions whenever the code spans more than one page.
    – whuber
    Jun 21, 2013 at 14:40
  • Changes like that usually won't affect whether the code works or not, though. If you're familiar enough with the language in the code block to know how it treats whitespace, then I don't think removing blank lines is a problem. Adding, changing or deleting non-whitespace characters is the issue.
    – user3461
    Jun 22, 2013 at 12:05
  • @GeoKevin You're right, changing whitespace usually is not an issue ... except for Python code, unfortunately. And it can have subtle effects in some languages where a blank line can terminate the preceding line which otherwise might be continued onto the next non-blank line.
    – whuber
    Jun 24, 2013 at 14:44
  • That is a good example of editors making sure they knew the effects in the particular language before they removed whitespace in any code.
    – user3461
    Jun 24, 2013 at 15:01
10

In my opinion, code in the original question should not be fixed to remove the problem. It really makes it impossible to understand the question later on.

On the other side, not to be rude, but this kind of question (which is based on a typo or basic syntax error) is pretty much worthless anyway. Whom is it going to help in the future? So I really don't care that much.

1
  • 3
    I agree, but it's worth noting that closing questions that arise from syntax errors would eliminate (at a guess) a few hundred questions right away (most of the Field Calculator questions).
    – whuber
    Jun 18, 2013 at 22:13
6

As the reviewer who rejected the change to the code, I agree very strongly with GeoKevin, whuber and underdark on this. The original code should be left alone.

Perhaps, to address whuber's point about simple syntax errors, is it possible and desirable to add a new Reason For Closing option as 'simple syntax error' (instead of, say, 'too localized')? The presumption would have to be that the reviewer would add a comment to note what the correct syntax should be. I realise that you can effectively do this by choosing the custom option and type a note, but given the apparent prevalence maybe the addition of this option is worthwhile as it allows for the rapid closing of such questions without requiring the original code to be changed but also giving anybody who sees the thread an explicit reason why it was closed.

1
  • 3
    That's a good idea. When the new closing mechanism is rolled out, we should be able to add site-specific reasons for closing.
    – whuber
    Jun 21, 2013 at 14:38

You must log in to answer this question.