We’re rewarding the question askers & reputations are being recalculated! Read more.
29

If the code produces wrong answers for some test cases, then the author is aware that the code is not working correctly as intended, and the question is thus prima facie off-topic for Code Review. There may be room for certain exceptions, though: If it's failing due to time limits rather than correctness, then that is an issue of scalability, which is OK. ...


23

I prefer to err on the side of commenting and closing, rather than fixing the code for them. Reasons include: 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. I'd prefer not to debate what ...


21

If you don't do VBA, you probably don't know this, but most VBA host applications are single-threaded, and when VBA code runs for a long time it's completely normal that the main window's caption says "(not responding)" until the code completes. THIS IS NOT BROKEN CODE. So please stop downvoting and voting to close Excel/VBA questions as "broken code" ...


18

OP doesn't seem to know their code is broken. Perhaps due to insufficient testing, but to the best of their knowledge, the code works and produces the expected output. The "spirit" of the "working code" rule isn't to forbid code with bugs - in fact part of the peer review exercise is to highlight unforeseen edge cases and other issues - it's very possible ...


15

This site being Code Review, we require working code. We review excerpts of code that aren't complete programs. They could be library functions or even just a line or two of code. Let's not change our wording from "code" to "program" just because some users have an excessively liberal concept of what "working" means.


15

I will refer first to Stack Overflow's on-topic page, as your question (in its original form) would actually be a better fit there (emphasis mine): What topics can I ask about here? Stack Overflow is for professional and enthusiast programmers, people who write code because they love it. We feel the best Stack Overflow questions have a bit of ...


15

When you do a suggested edit, the only information besides the edit that is shown to reviewers is the edit reason. Yours was Fixed the answer in regards to the question. This does not indicate that you and the poster of the answer had agreed on this change. So the natural presumption was that you had chosen to make that change on your own. Yes, if ...


14

Code with known memory leaks (or other resource leaks, such as file descriptors) might be working or broken depending on the context. If it is code that is meant to be in a long-running process, then any memory leak could be considered a fatal flaw that renders the code broken, and therefore the question off-topic. On the other hand, a short-lived program ...


14

I'm one of the users who voted to close. I saw that at least two bugs were discovered, and that made me think the code is severely buggy and therefore troublesome to review. But I saw it wrong. After re-reading the post, the answers, and this meta post, I realized there's really only one small bug, truly an edge case as you said it, with a trivially easy ...


14

If that message isn't the intended behavior, and you're looking for a solution to that specific issue, the right thing to do is to post a MCVE that reproduces the problem on Stack Overflow. If that message isn't the intended behavior, and you don't care for a fix because executing a few million times isn't your use-case anyway, then you don't even need to ...


14

For this particular case, it's a common beginner error, that wouldn't show up during runtime unless the out-of-bounds reads lead to a win because it happened to look like 4 in a row. I've had plenty of errors like this when I was starting out. By voting to close questions because of errors like these, we're denying starting programmers the benefit of help ...


13

The rule states that the code must work correctly, to the best of the author's knowledge. Usually, if the author does not mention any known bugs, then it's an allowable question. That said, if the code is very obviously broken (won't run at all, or fails on a simple test case), I will generally close it anyway, because It would be unfair to skirt the rule ...


13

At first I thought it was working, later I have found a bug in the code. Should it stay or should it be deleted? Since you've thought it was all working prior to posting it, it is okay. Consider this snippet from the FAQ: To the best of my knowledge, does the code work? The non-working aspect of the code is still off-topic, though. But this shouldn't ...


13

If you ask yourself: Can you play a game of connect four with their code? And your answer is: Yes, except in some special case - which someone may be unlikely to test. Then no the question shouldn't be closed. Because it's likely the code works as far as the OP knows.


12

Other than extremely minor edits, I think the answer has to be NO. If I've got the capitalization wrong on a case sensitive variable/function/method/class name in one out of the 20 times I used it in the pasted source code, or if I missed a singular semicolon or parenthesis or closing brace in several, several lines of source code, this is a very minor edit ...


12

First of all, your edit is totally legit (thank you!), and it should have been approved. The edit was rejected because 2 of 2 reviewers voted so, and by the powers that be (the Stack Exchange software), that's enough to reject a suggested edit. Your next question might be why did those 2 users vote to reject? Only they can answer that. But I'll venture a ...


11

I think that when this happens, it stops being code the OP "owns or maintains", so we shouldn't allow this.


11

Who reviews the reviewers? Voters do. You have some options for this: Add a comment (if you have the reputation) Downvote (if you have the reputation), and if you downvote it is recommended that you also add a comment. You did the right choice by adding a comment. Given the number of questions and answers on this site, I don't expect everyone to ...


11

If we take a look at https://codereview.stackexchange.com/help/on-topic we see To the best of my knowledge, does the code work as intended? if the OP answered this for him/her-self with yes, then the question should be on-topic (if the other questions on the on-topic section could be answered with yes as well). That being said, it looks like the downvote ...


10

To the best of my knowledge, does the code work? It is very hard to tell, almost impossible actually, if the OP is aware of the flaw in the code. As I don't know the skill of the OP, here's what I think happened: The OP wrote the initial program. The OP noticed that one of the lines in the output was a bit off and therefore added the if-else code to ...


10

If the code executes, it should be free game to review. Depending on the use-case, you may never notice that there is a problem during normal operation. However, pointing out the leaks and fixes for them is quite valid as part of a review. For example, I commonly see c# questions with code in need of using statements. These could be considered memory ...


9

If it is a matter of a time limit, then the question is valid. This is because we would be reviewing performance, but if the application is giving the wrong results then it is broken code. This question looks like it is not giving the right results based on what the coding challenge constitutes as optimal playing. Your task is to find out whether Alice ...


9

In addition to @Simon's suggestions (commenting and downvoting), you have two more options: Edit the answer to fix a bug (if you are certain that a small change will take care of the problem) Post a rebuttal as a competing answer. In that case, it would probably pay off to advertise your new answer in chat, since the original broken answer already has so ...


9

I just voted to Reopen. My reasoning: As far as the poster knew at the time of posting, the code worked. The code works for most situations. Two people answered, so the poster can't fix the code anymore. I would feel differently about this without the two answers. If we can see quickly that the code is broken and express how to see that it's broken,...


9

Unfortunately, your question is based on a faulty premise. The code to be reviewed consists of a makeBst() function with one test case. That test case produces incorrect output: class BinaryTreeNode { constructor(value) { this.value = value; this.left = null; this.right = null; } } function makeBst(arr){ if(!arr || arr.length <= ...


8

Answers on Code Review are meant to be “these are issues I found in your code and this is how I would fix them”, not “this is how I would solve this task”. What this means is that you can't look at an answer by itself, you have to consider it together with the question. And if there is some issue in the code in the question that an answer missed, it doesn't ...


8

Reviewers find bugs all the time. That is, after all, one of the benefits of submitting your code for review. Nevertheless, Code Review is not a debugging service; we require the code to be in working order, to the best of the author's knowledge. So, the question is, what did the author know, and when did he know it? It's hard to definitely prove that ...


8

Deleted my previous answer, it does not actually address your question.... I noticed the likely reason was vaguely stated: To the best of my knowledge, does the code work? Is it work as intended, or run without errors? Neither. It is somewhat intentionally loose. Defining exactly what 'working code' is will never be successful. What's ...


8

It is unreasonable to insist that code posted for review has no bugs. It is reasonable to require that code posted for review has no known bugs. The rule exists so that we can concentrate on improving working code, without being distracted by "please look at my code and fix it" questions that would achieve their purpose better if stripped down to an MCVE ...


8

The short answer is, if you know that your code has deficiencies that need to be fixed, then it is not ready to be reviewed here. In general, we expect questions to have no known bugs. It might be OK to declare known issues, but only if you consider them to be insignificant or irrelevant for your intended deployment. Otherwise, you should fix those issues ...


Only top voted, non community-wiki answers of a minimum length are eligible