4
\$\begingroup\$

I recently made a suggested edit to a post: https://codereview.stackexchange.com/review/suggested-edits/149799

In brief, I added an import statement (library(dplyr)) to the code in the question, because the code is not runnable without importing the relevant library (I should know, since I answered the question and couldn't run the code initially until I ran the statement I added). I tried to capture this with the suggested edit comment: "Add a necessary library include to make the code runnable"

The suggested edit was unanimously rejected, with the following two reasons:

  • This edit deviates from the original intent of the post. Even edits that must make drastic changes should strive to preserve the goals of the post's owner.
  • The edit does not improve the quality of the post. Changes to the content are unnecessary or make the post more confusing.

Both of these reasons seem wrong to me -- clearly it's not a drastic change and clearly it's not unnecessary or confusing (it's needed to make the code runnable, which is a requirement of all code posted on this site).

Was there something I could have done to improve my suggested edit (e.g. a better comment)? Is this just a hiccup where I got two unlucky reviewers and the suggested edit was fine?

\$\endgroup\$
2

1 Answer 1

6
\$\begingroup\$

This would've been better as a comment.

Code edits in questions are almost always rejected unless they're discussed in the comments first. Reviewers in the edit queue won't know all languages and won't know all the details of a post. So you may well have been right, but you can't expect the reviewer to know that. If code in a question seems flawed, the proper action is a comment. If the code is not reviewable without the change, the proper action is a comment and flagging/voting to close.

There are more pragmatic reasons for this. One of them is that some IDE auto-import missing libraries and thus the imports won't have been part of the original code. That's a reviewable point and we don't edit reviewable points into the question (unless they're obvious copy-paste mistakes).

Considering you've already answered the question, you might as well point it out in your answer instead of in a comment. It wouldn't have been worthy of an answer by itself in my opinion, but it's perfectly acceptable to add it to your own, already existing, valid answer.

\$\endgroup\$
4
  • \$\begingroup\$ Interesting. Noting that many users on your site can't make comments (codereview.stackexchange.com/help/privileges), don't you run the risk of missing out on these sorts of suggested edits? \$\endgroup\$
    – josliber
    Commented Jan 18, 2022 at 19:30
  • 2
    \$\begingroup\$ To extend the 3rd paragraph in Python the order and spacing of imports is normalized and normally there are two newlines after the imports. The process of "just adding an import" can cause there to be at least two (somewhat trivial) talking points. If someone adds the imports incorrectly then we'd be opening the OP up to unhelpful answers. \$\endgroup\$
    – Peilonrayz Mod
    Commented Jan 18, 2022 at 19:39
  • 1
    \$\begingroup\$ I concur with this, particularly the final paragraph. I review a lot of C and C++ where necessary header includes are omitted (and often unnecessary ones are present). If you can make it compile more portably, then that's worth a sentence (occasionally two) showing what you did to fix it, early in the review. \$\endgroup\$ Commented Jan 18, 2022 at 20:21
  • \$\begingroup\$ @josliber That's part of how the Stack Exchange network operates. Yes, we risk missing out. No, that doesn't provide enough reason to modify our approach. Getting enough reputation to make comments is not considered to be difficult. It's a necessary evil, unfortunately. \$\endgroup\$
    – Mast Mod
    Commented Jan 18, 2022 at 21:15

You must log in to answer this question.

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