Tag Info

Combining a few things here.... Tag wikis. Absolutely. The tag wiki should be used as an entry point to 'faq' type issues for that language/tag. Using meta.... Absolutely not. Single Question for all issues with one tag. Like this.... for C# No. All questions should conform to the on-topic requirements. This one does not. Solution? Seems easy to me: ...

Personal hat on, not mod hat Burn-out? It is real, and I recommend you be more selective about what questions you answer. Code Review (this site) should be fun for you. If you are not enjoying the process, then something is wrong, and we should try to fix it. Without people willing to answer the questions, then our site will languish, but, you can't feel ...

Note: This is just an idea. A thought. I do like rolfl's answer First of all, is there anything essentially wrong with pointing out the same mistakes every time? Except the fact that it can get boring and is tedious to write enough text to explain the issue? I think that for as long as C++ compilers accept using namespace std;, people are going to continue ...

Obviously, SQL injection is a major source of anxiety among beginner PHP programmers. It doesn't help that the deck is stacked against them: The language makes it easy to do the wrong thing and hard to do the Right Thing. Learn PHP in n Hours books gloss over the subject, and even teach them to do the wrong thing. There are a lot of bad examples out there. ...

From my own personal experience, finding accurate information regarding SQL injection, and even basic PHP security, is actually quite difficult for the novice. A search on Google can bring the best of tutorials and the worst of home-made blog posts. For the rookie, it all seems to work. I think if we could offer these guys a good resource that stays up-to-...

For those unaware, there's an old Meta question that did the same thing for Python: Python - Common Improvements It received a historical lock specifically because it didn't belong on Meta in the first place (doesn't pertain to the site itself), but it was also too valuable to delete. It's also too old to migrate, so if it should be added to this ...

As you've seen, I've experimented a bit. Sorry for jumping the gun and going ahead like this, I hope not too much damage was done. I've given this lots of thought lately, and I come to a conclusion that's radically disagreeing with the idea. Should we have such CW questions/answers? No. It's useless, redundant and counter-productive. Ok that was brutal. It'...

Experiment one did not really work. I have rolled back the C++ tag wiki page. With the minor addition of a couple of lines at the top: As an experiment I am starting to collect snippets of common Code Review things that happen repeatedly here: Code Review I have started a github repository. CodeReview If you want to help fill out this repository (...

Yes, and No Let's be clear here, the code works for the purpose given. The code presented will never be called in a way that exposes that bug, so is it a bug? Not for the asker. That code is not intended for review but is intended to provide background for the actual algorithm/process he wants to accomplish. The bug is only a bug if you extend the usage of ...

For me an answer is related to a question. An answer about formatting and naming the vars correct is also a very common answer. Do we have to redirect them to answers of the other questions for that? That said, I think I would vote to close the second one as duplicate or broken code if the first answer already has the duplicate answer before the posting of ...

I'm not sure it's entirely appropriate to mark any questions concerned about injection as duplicates of any other question. Why? Because it's not a duplicate question. It's a new question about the same topic. The appropriate response may be to down vote the question and leave a comment suggesting some reading material on the subject. I'm not convinced that ...

This thought occurred to me as well, after writing this exception-centric answer, this SOLID tutorial and this comment-centric answer. I completely agree with @svick's comment: This sounds like a good idea to me. If we go forward with this, such questions should probably be marked as community wiki. After reviewing code for a while, it turns out a lot ...

Instead of one artificial question with several carefully-crafted answers, you could: Wait until a real question is posted with one of these "common, core issues" Post a carefully-crafted answer which addresses one issue Add a link to your answer, to the corresponding language-specific tag wiki, as suggested in 200_success's and rolfl's answer. Example of ...

Tag wikis are repositories of language- or topic-specific information. I think they could be perfect for checklists like these. As an example, the sql tag wiki currently has a checklist of items to include in a good question. Tag wikis are currently an underused feature of the site, and may be a bit obscure. However, that's a bit of a chicken-and-egg ...

Contrary to what Mat's Mug wrote, I think the canonical question should not contain any code. I think that each answer should be independent and that when someone clicks on the “see here for more” link in a normal answer, they shouldn't be required to read lots of code that is not relevant to that issue. Also, if I want to add a new canonical answer, that ...

One possible way we could approach this would be to ask (and answer) questions on Stack Overflow like this one: https://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice It also has the advantage that if there are different views or tradeoffs, these are likely to be more fully discussed (in the form of multiple answers) ...

This started off with a two-way duplicate; That is, two questions contained the same code-pattern. In that light, I would have said "each question is separate". If a question happens to contain the same code(pattern) as another, it's perfectly valid to post answers on both questions listing the same points. Just make sure your answer is valid (if they say "...