-1
\$\begingroup\$

Translating array pointer access from C++ to Delphi

I agree that the question should not be deleted for minor problems like that (Should mostly working but a little bit broken code stay or be deleted?). But should the question be answered? I am afraid that reviewing broken code (no matter how simple would be to fix) is not healthy in the long term.

Would it be better for the reviewer to fix the minor problem directly in the question, before answering?

\$\endgroup\$
  • \$\begingroup\$ Come on guys, I don't know why you are downvoting this. \$\endgroup\$ – cpicanco Nov 26 '15 at 20:20
  • 4
    \$\begingroup\$ Probably because your suggestion to fix the problem by editing the question completely contradicts the question-and-answer nature of this site. \$\endgroup\$ – 200_success Nov 26 '15 at 20:22
  • 1
    \$\begingroup\$ also: meta voting is different. It doesn't generally imply that the question is of bad quality, but can also signal that people disagree with your ideas \$\endgroup\$ – Vogel612 Nov 26 '15 at 20:27
  • 2
    \$\begingroup\$ In what way is reviewing broken code not healthy in the long term, and why would you consider fixing the problem directly in the question as healthy? \$\endgroup\$ – Simon Forsberg Nov 26 '15 at 20:36
  • \$\begingroup\$ Simon, you were right. Fixing broken code is not healthy either. \$\endgroup\$ – cpicanco Nov 27 '15 at 4:32
11
\$\begingroup\$

First of all, you must never fix a bug in the question just by editing the question. This is Code Review, not GitHub hack fest. (The only possible exception would be obvious trivial whitespace issues due to the author's inability to copy-paste the code correctly into the text box.)

  • If the question specifically asks for help to get the code to compile, fix a bug, or add a feature, then it's off-topic. Please don't answer it, as it limits our ability to regularize the question.

    Ideally, we would close it, let the author fix the problem, then reopen it for a code review. Once an answer that reviews the broken code has been posted, though, we can't do that anymore. The question stays in limbo forever, which is not good for anyone.

  • Otherwise, if the code is broken, then it requires a judgement call.

    Is it obviously broken, as in "you obviously didn't test this code at all"? If so, it should be considered off-topic. Close/flag it, leave a comment, and don't answer.

    If it's plausible that the author was unaware of the brokenness, then it's a fine question. One of the purposes of Code Review is to point out problems that the programmer didn't know about.

\$\endgroup\$
  • \$\begingroup\$ Sorry, by I am not sure how to conciliate the binary approach (broken/not broaken) with the "unaware of the brokenness" rule. Could you extend the discussion a little bit about it? \$\endgroup\$ – cpicanco Nov 26 '15 at 20:29
  • 7
    \$\begingroup\$ @cpicanco It's rarely possible to test code to 100% and be 100% confident that it works. It's often bound to be an edge-case somewhere. That is why we allow the "unaware of the brokenness" case. Reviewing code that has a little edge-case that doesn't work is often more helpful than closing the code for being broken. If you want to have a long discussion about this then you should consider taking it to chat, or you might want to lookup previous meta questions about the subject, or start a new meta question. \$\endgroup\$ – Simon Forsberg Nov 26 '15 at 20:40
3
\$\begingroup\$

The point of closing a question is that it cannot receive any new answers. That's because it has problems that effectively prevent a useful answer.

As such questions with broken code can be considered questions that shouldn't be answered.

The point you raise here is somewhat understandable, and seems well intentioned, but there is a problem with it:

Answering a question sends the signal that these questions are "okay" for this site. The point is. They aren't. Code is rather binarily broken (or not). This is to simplify understanding and enforcement of that rule. Allowing "minor broken" on the site would make this a game of drawing a line in the sand.

That makes for a bad user-experience for any user. Those involved in moderation and those "moderated". Lines drawn in the sand are not transparent. The goal of close-reasons is the opposite.

Let's not draw lines in the sand and keep our simple "binary" rules, even though that model may be oversimplifying things

\$\endgroup\$
  • \$\begingroup\$ So, "minor broken" is broken or not? I honestly don't know. \$\endgroup\$ – cpicanco Nov 26 '15 at 20:12
  • \$\begingroup\$ I have edited the question, please take a look. \$\endgroup\$ – cpicanco Nov 26 '15 at 20:13
  • \$\begingroup\$ There is no such thing as "minor broken". It's either broken or it's not broken, \$\endgroup\$ – Vogel612 Nov 26 '15 at 20:15
  • \$\begingroup\$ Please, note the specific answer tag. \$\endgroup\$ – cpicanco Nov 26 '15 at 20:16
  • \$\begingroup\$ @cpicanco the generalistic answer still applies \$\endgroup\$ – Vogel612 Nov 26 '15 at 20:24

You must log in to answer this question.

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