19
\$\begingroup\$

I know, I know: "Never edit the code, leave it for the review!". But please, hear me out before answering.


What should I do if I encounter a code that doesn't work, but I'm 99.99% sure it's because OP was trying to adapt the code to fit the format of this site?

There are a few situations where this can happen:

  • OP has added comments, but on the wrong format, so the code doesn't run
    • For instance used // instead of #, or % in front of comments.
  • Some variable names are mixed up, but it's quite clear what the intention is
    • A variable is named Mask through the entire code, except a few places where it's called Masque. It's very likely that this is because OP has translated the variable names from her/his native language so that it's clear for everyone what it means.

Note:

I've tested the code in the question and it doesn't run as it is. When I make the changes I suggest it runs and produces the same output OP has provided. OP doesn't respond to comments.

Questions:

  • Should such a question be closed since it contains broken code?
  • Can I edit the question if I'm 99.99% sure my edit is correct, since I've tested it and reproduced OP's results? (I know this goes against the general rule: "Don't edit code! Leave it to the review", but in this case it's not really up for review)
  • Should I just leave it be?

The question that made me ask this question: https://codereview.stackexchange.com/questions/126336/inpainting-algorithm-using-conjugate-gradient-for-colored-images-using-matlab#comment257440_126336

\$\endgroup\$
  • \$\begingroup\$ An option is to vote to close as unclear what you are asking in situations like this, that might be less "brutal" than just classifying it as broken code. \$\endgroup\$ – Simon Forsberg Aug 16 '16 at 11:37
23
\$\begingroup\$

I prefer to err on the side of commenting and closing, rather than fixing the code for them. Reasons include:

  1. Fixing broken code is a slippery slope. Newer users will see that and assume that editing code in questions is an acceptable practice, without understanding the general principle that code should remain unchanged.
  2. I'd prefer not to debate what constitutes a "minor" change. The current practice, which is to help posters correct copy-and-paste problems so that the the code is represented as intended, is easy to understand.
  3. Code review works best when everyone can be assured that the code can be taken literally, without guesswork. Computers are mercilessly exact. Programmers need to be equally meticulous. Code reviewers should help spot everything that might be wrong with the code, considering that even incorrect punctuation could crash a rocket.
  4. Wrong variable names and syntactically incorrect comments suggest that the code is not real, but fabricated for the sake of the question. For example, I've been burned by one question where Python code contained curly quotes. I thought it was safe to ignore it, but it turned out that the author was asking to review drastically simplified code, and my answer turned out to be useless. (Also, for this reason, I've always been adamant that we allow code with non-English identifiers to be posted as-is, rather than asking the author to Anglicize it for the sake of posting on Code Review.)

Furthermore, if the author isn't bothering to responding to requests to fix the question, that's a sign that we should just close the question rather than waste time giving advice to a black hole.

\$\endgroup\$
5
\$\begingroup\$

IMO the code of a question should never ever be edited. The only exception to this rule is if it is a clear copy&pasta error. If the OP knows the language well enough I assume he/she could edit his/her question targeting the comment problem and also the variable name problem.

We at least expect some effort from the OP because we have also have some effort to answer the question.

If the user doesn't react to comments then its his/her problem.

\$\endgroup\$

You must log in to answer this question.

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