Tag Info

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

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

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

It is likely that a review of one piece of code by a programmer will turn up issues that are found throughout the work of that programmer. So if you post several pieces of code in quick succession, it is likely that a common set of issues will be found several times over. It will be more productive if you post one piece of code, receive feedback, and make ...

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

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

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

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

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

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

Loops In Python you should rarely use while loops or for x in range(n) loops. Python has a wide variety of tools like zip, enumerate, itertools.* to iterate over pretty much anything with a for loop and an iterator. Don't write: for x in range(len(data)): print(data[x]) instead write: for item in data: print(item) Don't write: for x in range(...

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

file handling Instead of closing files yourself, have the with statement do it for you: with open('filename') as filehandler: do_stuff(filehandler) and not: filehandler = open('filename') do_stuff(filehandler) filehandler.close() Beyond saving you to have to close the file manually, the with statement also ensures the file will be closed even though ...

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

PEP 8 -- Style Guide for Python Code To follow a standard coding style is very important. It's even more important if you want other people to look at your code. By following the official coding style guide your code will be more readable and it will be way more easy for others programmers to understand it. You should really read PEP8, it may seem long, ...

So far nobody opposed to the creation of these Language References so I'm going to assume there are no major conflicts. From the comments received so far two problems came out: Where: Commuity wiki post. Tag wiki of the language. How to link it. At first when the tag wiki option came out I was for it. But now I'd go with a Community wiki post. It will ...

Have as little code as possible in the global namespace. Most logic should be in functions, classes, or methods. This helps prevent polluting the global namespace and will run faster. On a related note, the main function should look something like this: def main(list_of_stuff): ... if __name__ == "__main__": main(sys.argv) This is to avoid the ...

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

Naming: classes: NameOfClass() constants: NAME_OF_CONSTANT all else: name_of_function(), name_of_variable general: avoid abbreviations in names (e.g. cnt should be counter)

Consider this: if (check): do_something() This should be written as: if check: do_something() That is, you don't need to put stuff in brackets.

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