"How to Ask Questions": Itemized thread/rehash
I'm sure all of us are familiar with the famous "How to ask question the smart way" guide.
I don't necessarily want to reinvent the wheel here, but I have some beefs with the guide that inspired me to make this thread.
Specifically:
- The original guide is too big. It's like a 10 page thing. Often when I want to draw people's attention to it, I just want to draw their attention to a specific paragraph, which isn't very convenient.
- I don't agree with all of it. Specifically the amount of research he expects people to do.
- It's too broad and doesn't cover some really specific things that I see often on these particular boards.
So the goal of this thread is to address those issues and allow the userbase here to contribute some of their own tips.
The idea is simple, but in order to keep it useful I would like to introduce some "rules" for posting new tips:
- 1 item per post. That way individual items can be linked instead of having to link to one massive article. This way when these tips are "broken", we can link the user to the direct post rather than directing them to a general guide.
- Put a one-line summary of the tip in bold (and possibly in caps -- just make it noticable) at the top so that when the person clicks on the link, it's immediately clear what they did wrong.
- Try to keep each item short. People aren't going to read a whole page. In order for this to be effective we need to avoid the tl;dr.
That's about all I can think of for now. I'll start off with a few that get my goat. More are welcome.
I don't necessarily want to reinvent the wheel here, but I have some beefs with the guide that inspired me to make this thread.
Specifically:
- The original guide is too big. It's like a 10 page thing. Often when I want to draw people's attention to it, I just want to draw their attention to a specific paragraph, which isn't very convenient.
- I don't agree with all of it. Specifically the amount of research he expects people to do.
- It's too broad and doesn't cover some really specific things that I see often on these particular boards.
So the goal of this thread is to address those issues and allow the userbase here to contribute some of their own tips.
The idea is simple, but in order to keep it useful I would like to introduce some "rules" for posting new tips:
- 1 item per post. That way individual items can be linked instead of having to link to one massive article. This way when these tips are "broken", we can link the user to the direct post rather than directing them to a general guide.
- Put a one-line summary of the tip in bold (and possibly in caps -- just make it noticable) at the top so that when the person clicks on the link, it's immediately clear what they did wrong.
- Try to keep each item short. People aren't going to read a whole page. In order for this to be effective we need to avoid the tl;dr.
That's about all I can think of for now. I'll start off with a few that get my goat. More are welcome.
THREAD TOPICS ARE FOR SUMMARIZING YOUR QUESTION
Lots of people here don't read every thread. We filter them based on what the topic says. If your topic accurately describes your problem, it's more likely to get a response.
Examples of bad thread topics:
"A quick question": doesn't describe anything
"How do I...": Incomplete sentence. Finish the sentence and maybe it would be a good topic.
"Getting compiler errors" Better, but still not very descriptive
Examples of good thread topics:
"Numbers printed to the screen aren't showing up right"
"Using vector, program crashes on exit."
TELL US WHAT COMPILER ERROR YOU'RE GETTING
Compiler errors often tell you exactly what's wrong with the code. They take experience to fully understand, but the regulars here all have that experience and know how to read them.
Do's:
- Copy paste the error as the compiler tells it to you
- Show us the line of code that is causing the compiler error
Don'ts
- Don't tell us you're getting error C2203. We don't know what that is.
- Don't paraphrase/reword the error. Chances are you're leaving out/changing some critical information that we need.
WHEN POSTING CODE POST RELEVANT PARTS
Some people ask question posting the whole source of their programs or only a tiny fraction which doesn't reproduce the problem. Neither of these approach will help them getting a proper answers.
Hints:
- The problem may be some lines above what the error message points to
- A single error may cause a flood of messages, focus on the first one
- An issue with a function may be a combination of errors in: it's prototype, it's body, the way it's called
Do's:
- Try to locate exactly where the error is
- Try to reproduce the error in a simpler program
- Use [code][/code] tags
Don'ts:
- Don't post hundreds of lines of code
- Don't post code which is different from your own but does not reproduce the problem ( or has other problems )
- Don't post only a single line of code if you are unsure that it is the specific location of the error
Last edited on
TELL US WHAT THE PROBLEM IS
Don't post a chunk of code and say "This code doesn't work." Be specific about why it doesn't work.
- Do you get errors when you try to compile? If yes, tell us what and where the errors are.
- Does the program not do what you want when you run it? If yes, tell us what you want it to do, and what it actually does.
We can't solve a problem when we don't know what the problem is.
AVOID POSTING TRIVIAL QUESTIONS
If you are wondering something like "Should I use a reference operator or a dereference operator when addressing my pointer?", don't ask us, try it. It takes less time for you to change a few characters and test your application then it will for one of us to reply to your post.
Mythos
1.) I'll break my computer.
2.) It might cause an error and I'll lose all of my <insert E-mail, school reports, pictures of grandma, etc.>.
3.) All of my memory will leak out and my computer won't work.
Reality
the following statements may be invalid in a Windows ME environment
1.) There are so many layers seperating the software and hardware that you cannot accidently write anything that will physically damage your computer.
2.) Unless you are telling your program to save over those files, then nothing your program does can effect data stored on your hard drive. *The pagefile is an exception but if you're about to point that out then you already know that you're being pedantic.
3.) A memory leak is when memory is constantly allocated to a program and is not released. Once the application closes all of the memory that was allocated to it is freed automatically by a system process called a "Garbage Collecter"; this resolves the issue. *There is a well known bug in some versions of Windows where memory is not deallocated correctly when an application is closed, this will happen regardless of any errors in your program and is fixed with a simple reboot so don't let it stop you.
Last edited on
Addition to the above:
Wrong code usually won't compile ( or gives warnings ), if it doesn't compile it can't harm...
Wrong code usually won't compile ( or gives warnings ), if it doesn't compile it can't harm...
Topic archived. No new replies allowed.