Skip to main content
Code Review

Return to Answer

replaced http://meta.codereview.stackexchange.com/ with https://codereview.meta.stackexchange.com/
Source Link
Community Bot
Community Bot
  • 5
replaced http://meta.codereview.stackexchange.com/ with https://codereview.meta.stackexchange.com/
Source Link
Community Bot
Community Bot
  • 5

  1. Don't know and own the code, Both owner of code and explanation of code link to the same answer in our close-reason meta thread. I also don't like the idea of separating these as I don't particularly wish for us to go on witch hunts to check out if it is someone else's code. It's also more than likely that if you're asking what the code does that you don't own it, otherwise you could read it yourself and after a while understand what it's doing.

    This makes the close reason simple, does the asker say it's someone else's code or ask what it does.

  2. Lacks reviewable code, all have a lack of code. None of pseudocode, stub code, hypothetical code or code not (yet) written have enough code to do a proper review. I'd also include the 'no code' close reason in this section too, it can fit quite well if we phrase it nicely, something like 'or if you forgot to include the code in the question.'

    This would make the close reason simple, if there are no code blocks or if the code blocks are not 'real' code.

  3. Code not working as intended, is our largest close reason, and so having it on its own will allow us to better explain to users what is wrong with their code. Currently our broken code reason confuses new usersbroken code reason confuses new users, so this gives us the option to change the entire close reason to fully and clearly explain what is wrong.

    This will make the close reason simple as if you cannot compile or run the code, it produces incorrect results or it doesn't contain the features the asker wants then it does not work as intended. The same as before and as simple.

  1. Don't know and own the code, Both owner of code and explanation of code link to the same answer in our close-reason meta thread. I also don't like the idea of separating these as I don't particularly wish for us to go on witch hunts to check out if it is someone else's code. It's also more than likely that if you're asking what the code does that you don't own it, otherwise you could read it yourself and after a while understand what it's doing.

    This makes the close reason simple, does the asker say it's someone else's code or ask what it does.

  2. Lacks reviewable code, all have a lack of code. None of pseudocode, stub code, hypothetical code or code not (yet) written have enough code to do a proper review. I'd also include the 'no code' close reason in this section too, it can fit quite well if we phrase it nicely, something like 'or if you forgot to include the code in the question.'

    This would make the close reason simple, if there are no code blocks or if the code blocks are not 'real' code.

  3. Code not working as intended, is our largest close reason, and so having it on its own will allow us to better explain to users what is wrong with their code. Currently our broken code reason confuses new users, so this gives us the option to change the entire close reason to fully and clearly explain what is wrong.

    This will make the close reason simple as if you cannot compile or run the code, it produces incorrect results or it doesn't contain the features the asker wants then it does not work as intended. The same as before and as simple.

  1. Don't know and own the code, Both owner of code and explanation of code link to the same answer in our close-reason meta thread. I also don't like the idea of separating these as I don't particularly wish for us to go on witch hunts to check out if it is someone else's code. It's also more than likely that if you're asking what the code does that you don't own it, otherwise you could read it yourself and after a while understand what it's doing.

    This makes the close reason simple, does the asker say it's someone else's code or ask what it does.

  2. Lacks reviewable code, all have a lack of code. None of pseudocode, stub code, hypothetical code or code not (yet) written have enough code to do a proper review. I'd also include the 'no code' close reason in this section too, it can fit quite well if we phrase it nicely, something like 'or if you forgot to include the code in the question.'

    This would make the close reason simple, if there are no code blocks or if the code blocks are not 'real' code.

  3. Code not working as intended, is our largest close reason, and so having it on its own will allow us to better explain to users what is wrong with their code. Currently our broken code reason confuses new users, so this gives us the option to change the entire close reason to fully and clearly explain what is wrong.

    This will make the close reason simple as if you cannot compile or run the code, it produces incorrect results or it doesn't contain the features the asker wants then it does not work as intended. The same as before and as simple.

Reversed the order, and reworded. https://chat.stackexchange.com/transcript/message/29548506#29548506
Source Link
200_success Mod
200_success Mod
  • 144.1k
  • 4
  • 113
  • 280
  1. Code not working as intendedOwner of code | Explanation of code
  2. Pseudocode, etc. | Code not written yet | No code
  3. Owner of code | Explanation of codeCode not working as intended

  1. Code not working as intendedDon't know and own the code, is Both owner of code and explanation of code link to the same answer in our largest close reason,-reason meta thread. and so having it on it's own will allowI also don't like the idea of separating these as I don't particularly wish for us to better explaingo on witch hunts to users whatcheck out if it is wrong with theirsomeone else's code. Currently our broken code reason confuses new usersIt's also more than likely that if you're asking what the code does that you don't own it, so this gives us the option to change the entire close reason to fullyotherwise you could read it yourself and clearly explainafter a while understand what is wrongit's doing.

    This will makemakes the close reason simple as if you cannot compile or run the code, it produces incorrect results or it doesn't contain the features does the asker wants thensay it's someone else's code or ask what it does not work as intended. The same as before and as simple.

  2. Lacks reviewable code, all have a lack of code. None of pseudocode, stub code, hypothetical code or code not (yet) written have enough code to do a proper review. I'd also include the 'no code' close reason in this section too, it can fit quite well if we phrase it nicely, something like 'or if you forgot to include the code in the question.'

    This would make the close reason simple, if there are no code blocks or if the code blocks are not 'real' code.

  3. Don't know and own the codeCode not working as intended, Both owner of code and explanation of code link to the same answer in is our largest close-reason meta thread. reason, I also don't like the idea of separating these as I don't particularly wish forand so having it on its own will allow us to go on witch huntsbetter explain to check out if itusers what is someone else'swrong with their code. It's also more than likely that if you're asking what the code does that you don't own itCurrently our broken code reason confuses new users, otherwise you could read it yourselfso this gives us the option to change the entire close reason to fully and after a while understandclearly explain what it's doingis wrong.

    This makeswill make the close reason simple, does as if you cannot compile or run the asker say it's someone else's code, it produces incorrect results or ask whatit doesn't contain the features the asker wants then it does not work as intended. The same as before and as simple.

  • Code not working as intendedDon't know and own the code - CodeSince Code Review is a community-run website where programmers offer toimprove their skills through peer review your correctlyof working code for security issues, readability, completeness, and optimal performance. Unfortunately, questionswe require that containall code be posted by an owner or maintainer of the code, and that don't work as intended are outside the scope of this siteposter understands how the code works.

  • Lacks reviewable code - Unfortunately,Code to be reviewed must be embedded directly in the question. Note that questions about pseudocode, stub code, hypothetical code or, code not yet written, or generic best practices are outside the scope of this site. Or you may have forgotten to include thesite; please post concrete code in the question. When you amend this we will consider reopening the question.

  • Don't know and own the codeCode not working as intended - For constructiveCode Review is a community where programmers peer-review your working code to address issues such as security, maintainability, and practical reasonsperformance. Unfortunately, we askquestions that allcontain code submitted for peer review be under the direct "ownership" and control of the author requesting the review, and said author understandsthat doesn't work as intended are outside the entirescope of their codethis site.

  1. Code not working as intended
  2. Pseudocode, etc. | Code not written yet | No code
  3. Owner of code | Explanation of code

  1. Code not working as intended, is our largest close reason, and so having it on it's own will allow us to better explain to users what is wrong with their code. Currently our broken code reason confuses new users, so this gives us the option to change the entire close reason to fully and clearly explain what is wrong.

    This will make the close reason simple as if you cannot compile or run the code, it produces incorrect results or it doesn't contain the features the asker wants then it does not work as intended. The same as before and as simple.

  2. Lacks reviewable code, all have a lack of code. None of pseudocode, stub code, hypothetical code or code not (yet) written have enough code to do a proper review. I'd also include the 'no code' close reason in this section too, it can fit quite well if we phrase it nicely, something like 'or if you forgot to include the code in the question.'

    This would make the close reason simple, if there are no code blocks or if the code blocks are not 'real' code.

  3. Don't know and own the code, Both owner of code and explanation of code link to the same answer in our close-reason meta thread. I also don't like the idea of separating these as I don't particularly wish for us to go on witch hunts to check out if it is someone else's code. It's also more than likely that if you're asking what the code does that you don't own it, otherwise you could read it yourself and after a while understand what it's doing.

    This makes the close reason simple, does the asker say it's someone else's code or ask what it does.

  • Code not working as intended - Code Review is a community-run website where programmers offer to peer review your correctly working code for security issues, readability, completeness, and optimal performance. Unfortunately, questions that contain code that don't work as intended are outside the scope of this site.

  • Lacks reviewable code - Unfortunately, questions about pseudocode, stub code, hypothetical code or code not yet written are outside the scope of this site. Or you may have forgotten to include the code in the question. When you amend this we will consider reopening the question.

  • Don't know and own the code - For constructive and practical reasons, we ask that all code submitted for peer review be under the direct "ownership" and control of the author requesting the review, and said author understands the entire of their code.

  1. Owner of code | Explanation of code
  2. Pseudocode, etc. | Code not written yet | No code
  3. Code not working as intended

  1. Don't know and own the code, Both owner of code and explanation of code link to the same answer in our close-reason meta thread. I also don't like the idea of separating these as I don't particularly wish for us to go on witch hunts to check out if it is someone else's code. It's also more than likely that if you're asking what the code does that you don't own it, otherwise you could read it yourself and after a while understand what it's doing.

    This makes the close reason simple, does the asker say it's someone else's code or ask what it does.

  2. Lacks reviewable code, all have a lack of code. None of pseudocode, stub code, hypothetical code or code not (yet) written have enough code to do a proper review. I'd also include the 'no code' close reason in this section too, it can fit quite well if we phrase it nicely, something like 'or if you forgot to include the code in the question.'

    This would make the close reason simple, if there are no code blocks or if the code blocks are not 'real' code.

  3. Code not working as intended, is our largest close reason, and so having it on its own will allow us to better explain to users what is wrong with their code. Currently our broken code reason confuses new users, so this gives us the option to change the entire close reason to fully and clearly explain what is wrong.

    This will make the close reason simple as if you cannot compile or run the code, it produces incorrect results or it doesn't contain the features the asker wants then it does not work as intended. The same as before and as simple.

  • Don't know and own the code - Since Code Review is a community where programmers improve their skills through peer review of working code, we require that all code be posted by an owner or maintainer of the code, and that the poster understands how the code works.

  • Lacks reviewable code - Code to be reviewed must be embedded directly in the question. Note that questions about pseudocode, stub code, hypothetical code, code not yet written, or generic best practices are outside the scope of this site; please post concrete code.

  • Code not working as intended - Code Review is a community where programmers peer-review your working code to address issues such as security, maintainability, and performance. Unfortunately, questions that contain code that doesn't work as intended are outside the scope of this site.

Blasted broken codes. (I intentionally left the last one)
Source Link
Peilonrayz Mod
Peilonrayz Mod
  • 43.5k
  • 31
  • 75
Post Undeleted by PeilonrayzMod
I shouldn't have posted the previous answer it was poorly written. This is pretty much a complete re-write, and is what I should have posted.
Source Link
Peilonrayz Mod
Peilonrayz Mod
  • 43.5k
  • 31
  • 75
Post Deleted by PeilonrayzMod
Source Link
Peilonrayz Mod
Peilonrayz Mod
  • 43.5k
  • 31
  • 75
Post Made Community Wiki by PeilonrayzMod