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

"There are no wrong questions." Actually, I believe the phrase is that there are no bad questions, but the thing is, I have to disagree — at least in the context of a question and answer site. The phrase "There are no bad questions" is meant to encourage one who does not know to ask rather than to continue on in ignorance. But the phrase also doesn't mean ...


19

I found working on this jigsaw puzzle a personally rewarding experience. It really helped me appreciate what you do here. Obviously the longer your site has been around, the more problems you find that need addressing. I'm sure you've tried cramming more unrelated close reasons into each slot, but that becomes unwieldy fast. I've been developing a better ...


18

As I see it, some of the problems with the existing close reasons are: Ambiguity of "broken code". Some users seem to think that anything that compiles is not broken. Accusations of "not real code". Sometimes, it's hard to tell whether code is real or not. Occasionally, we misjudge, and the author feels insulted by our accusation that their real code is ...


17

I think the close vote is inappropriate. The close reason says "author or maintainer". In this case I think it makes sense to assume that the poster is the maintainer of the cloned code, especially if the code has diverged so much that the original is unrecognizable due to the changes. That close reason intends to filter out questions asking to review ...


16

We've all been there one time or another, so we understand what your problem is. However, we simply can not throw this rule out of the window. It makes it unnecessarily hard on the reviewers and it would open the door for categories of questions we really don't want here. Please scour the meta for examples; I'll update this answer later with the most ...


15

Fixing non-obvious bugs is part of code review. What this means is that if the OP ran their code and it seemed to work, then such question is on-topic and shouldn't be closed. If you find a bug in the code, post it in your answer along with other things you want to mention. (But don't forget that you don't have to review everything.) One problem with this ...


15

No, there should not be. A question can only be put on hold by three means: Five users with 3,000 reputation or more (500 on beta sites) have cast a close vote. A user with a gold badge in one of the question's tags has marked the quesiton as a duplicate. A site moderator has put the question on hold. The evidence that the question should be on hold lies ...


15

I was the close voter. After some back-and-forth with the OP, I was eventually able to get the code to run, and I started writing a review, but after a bit I gave up, because the whole program is shoddy from start to finish. Everything about it shows a lack of care and attention. It seems to me that the OP was capable of doing better than this, and it was a ...


15

Yea that close-reason is a bit difficult. It's two, maybe three different reasons packed into one. "Authorship of code: Since Code Review is a community where programmers improve their skills through peer review, we require that the code be posted by an author or maintainer of the code, that the code be embedded directly, and that the poster know why the ...


15

No, we should not close it just because the user has not joined Code Review. If the question is on-topic, it should be treated just like any other question. Note that questions, answers, reviews are not only for the benefit of the question asker, but also for any other people that follow along. On the technical side, the user has not signed up to Code ...


14

I now agree that the wording can be unhelpful or even incendiary (possibly construed as an accusation of plagiarism, even). I propose: Questions must involve real code that you own or maintain. Questions asking how or why code works are off-topic. Pseudocode, hypothetical code, or stub code should be replaced by a concrete example.


14

Code Review is a community where programmers peer-review your working code to address issues such as security, maintainability, and performance. Questions about code that has not yet been written, code that does not work as intended, or code that the author does not understand are off-topic, as the code is not ready for review. I've clarified what we mean ...


14

I believe we should use 5 close reasons. This will significantly reduce the confusion people may express when they have to figure out which of multiple close reasons was actually used to close a question: Note, finding bugs is now in 2, and fixing bugs in 3 - this makes it clear that 2 and 3 could both relate to buggy code, but it is the way the question is ...


14

I think two things are important to note here: the question is not closed - only one person has voted with that close reason you can vote to "leave open". This is the system working the way it is supposed to work. Someone sees a problem, uses a custom close reason, and votes to close. Only if others in the community agree with that close reason will that ...


14

I was one of the users that voted to close this question. First and foremost I did this not because the "question" was actually unclear. Basically closing the question as "unclear what you're asking" on this site is impossible, since any question asks for a codereview of all aspects by definition. Lately we've begun using "unclear what you're asking" as a ...


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 ...


13

Pretend you never answered the previous review requests. Other reviewers might not have seen those and will point it out as well, so you could also ignore/walk away from his posts if you find it irritating, but odds are he's pasting different parts of his codebase into different review requests and that's perfectly fine. Though at one point he should take ...


13

Update: Feel free to close for either reason if a question lacks context in the description or code. It's common to close for LCC in both cases. Scenario 1 A user posts a full program without any description and a vague title. This is 'unclear what you're asking', as we don't know if the op want a review, if the code works, well really we don't know ...


12

My proposal: Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. Such questions may be more suitable for Stack Overflow or Programmers. After the question has been edited to contain working code, we will consider reopening it. Questions must include the code to be reviewed. ...


12

An excessively complex question deserves a comment suggesting that it be distilled. It might even attract a downvote for being a poorly formulated question. However, it does not deserve to be closed. If some intrepid reviewer decides to take it on anyway, why should the mob prevent it? Conversely, if the question languishes, it's the poster's own fault. ...


12

Code Review, like all Stack Exchange sites, limits questions to a certain topic. As stated on our tour and on-topic pages, the goal of Code Review is to take working code and make it better. Your question was asking about how to fix broken code, and was thus off-topic. There is a link in the off-topic message giving some general advice about what to do ...


12

This question is on topic in my opinion and I've voted to reopen it. It's OP's code. Even without context, it's a pretty clear question. The code isn't broken. OP isn't asking for new functionality, but for a better way to do the same thing. (i.e. not a feature request). Is it possible to remove the inner loop by assigning data.Data.Tables[0].Rows[i]....


12

Let me quote the help center here: However, if your question is not about a particular piece of code and instead is a generally applicable question about… Best practices in general (that is, it's okay to ask "Does this code follow common best practices?", but not "What is the best practice regarding X?") Tools, improving, or conducting ...


11

Actually, it was cross-posted to Stack Overflow, and it has an accepted answer there. You're correct that it belonged there, but there was no need to migrate it since the OP had already posted there. I'll add a comment to the post to make it clear. EDIT: Based on the discussion above, I've deleted our copy of the question. We have no answers or useful ...


11

Among the dozen-or-so comments under your post there, I've counted 5 links to meta.codereview.stackexchange.com where you should have posted this meta-question. Asking on MSE isn't really helping the community understand that you want to cooperate here. Your question has been put on hold by users with respectively 13.7K, 33.4K, 15.7K, 7.2K and 14.8K ...


11

Look, here's the way this question breaks down, along with some of my opinions, and some feedback on the flags that were raised. Closed, or no First up, let's talk about the merits of the actual question. Let me paraphrase the question as follows: I have this code it works it runs slow the first time it is called. subsequent times it runs faster. two ...


11

"Unclear what you're asking" is, paradoxically, unclear for Code Review, because every question is asking the same thing: "How can I improve this code?". I use it to mean, "Unclear what this code is supposed to achieve," and I use it for questions that have a code dump with no explanation of requirements, or an explanation that is so muddled or confusing ...


11

Use Comments and Chat You could leave a comment challenging the VTC. This way, both OP and the community are aware of the pending VTC and your concerns about it. OP may react to reflect on their question, or person that voted could explain their reasons. Any discussion should then be taken to chat. Some interesting links: Frequently Posted Comments (you ...


10

"...that will appropriately cover everything there is to cover..." Well that's the thing isn't it, we don't need to cover everything in our answers. For questions of excessive length, finding just two or three things to improve would be good enough. If they improve those things then they can post a new question later with those things improved (and ...


10

This one fits the best to me: Questions must involve real code that you own or maintain. Questions seeking an explanation of code are off-topic. Pseudocode, hypothetical code, or stub code should be replaced by a concrete example. It doesn't matter who's code it is. If it's your code then you should understand it already. If it's not your code, then you ...


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