I notice that there are many, many threads where posters receive few if any comments. When I open these threads, it is usually obvious right away why no one has bothered to reply. The problems with these posts vary from deliberate solicitation for homework solutions to poorly composed questions. I have assembled here 5 simple methods to make your post more interesting and clear to people who want to help you

1. Make your title descriptive
No one gets excited about clicking on a thread that says, "Please help!! T_T". The first thing I think when I see that link is, "This person is too lazy to summarize their problem, so the explanation inside is probably even worse." People on this forum want to help you, but they do not want to spend valuable time trying to deduce what the problem is. If you want people to read and reply, use a title that is descriptive of your problem. Here are some examples of interesting thread titles that will probably earn responses:

[B]Problem inserting nodes into linked list[/B]
[B]Compiler error in template class constructor[/B]
[B]Trouble sorting Automobile Class[/B]
[B]How can I return two values from a function?[/B]

It is most important that your title describes what kind of help you are looking for. I imagine that, like me, most readers skim the forum for interesting posts and ignore any that seem too inane. Finally, make sure that at least your title uses proper English. A thread title that reads "Please help to error of code" suggests that the content of the thread will be less than coherent. Many readers will suffer through broken English in a thread if the problem is interesting, but your title might turn them away before they even read your post.

2. Put your question before your code sample
One of the surest ways to guarantee that I won't read your post is to post a mile of code before you have even asked a question. Give your readers an idea of where they should look for problems before you bury them in your implementation. Generally, your post should follow this simple outline:

A.  Explain your problem
B.  Describe the steps/solutions you have tried so far
C.  Post example code
D.  Post output or compiler errors resulting from the previous code

Generally, the people who want to help you want to know what the problem is immediately so they can judge whether they know the solution. Everyone who would help you can read and write code, but few of them want to try to deduce the source of the problem. So, first provide a concise description of the problem then post the code that is causing the problem. It is also a great idea to reference problem areas by line number. This helps readers correlate conceptual problems to implementation problems. Remember, your readers are willing to work in order to help you, but expecting them to understand the problem before it's described is expecting too much.

3. Only post relevant code
If you have a specific problem that you have already clearly explained, only post the code that is relevant to the problem. Of course, you should post code that can be compiled, but try to keep the sheer number of lines down. You may have to strip down a class infrastructure to post it in a reasonable size. Less is more when it comes to reading other people's code. If you have identified a specific function that is causing an error, try to reduce your compiled code to the functions that lead into the trouble area. Stripping your code down to a trouble area can also help you determine if the error is caused by a previous mistake. Here's an example: Suppose you have a custom integer class that uses a char array to store its data. The original class you wrote looks like this:

class MyInt
{
    friend ostream& operator<<( const MyInt& num, ostream& out );
    private:
        char* arr;
        int l;
    public:
        MyInt();
        MyInt( int num );
        MyInt( const MyInt& other );
        MyInt( char* otherArr, int otherL );
        MyInt operator*( const MyInt& other );
        MyInt operator/( const MyInt& other );
        MyInt operator-();
        MyInt operator-( const MyInt& other );
        MyInt operator+( const MyInt& other );
        MyInt pow( int x );
};

Now, suppose that the only portion of your class that is giving you trouble is the / operator. Strip the class down, and post only the problem area:

class MyInt
{
    friend ostream& operator<<( const MyInt& num, ostream& out );
    private:
        char* arr;
        int l;
    public:
        MyInt( int num );
        MyInt operator*( const MyInt& other );
        MyInt operator/( const MyInt& other );
};

Posting less code makes it much easier for a reader to get right to the problem. It is also less distracting. If you post a lot of code that isn't relevant to your question, you risk a reader hijacking the thread to talk about how they don't like the way you implemented some other piece of code. If you want your specific question answered, post the specific code. If you just can't bring yourself to strip away irrelevant code, at least highlight the area where you are having trouble. Use either the bold or color tags to draw your readers' eyes to the portion you want help with.

4. Post output or complete error message
Now that you have used a descriptive title, posted a clear question at the beginning, and shown only relevant code, make sure that you let your reader see what happened when you compiled or ran the code. There is nothing more frustrating than reading a whole post and discovering that the reader said, "but there was a compiler error" or "and then it crashed." Crashed doesn't tell your reader anything useful. Copy and paste the output of the problem. Most often, your readers will compile the code themselves to try to find the error (if it isn't obvious), but it is helpful to give them an idea of where to start looking. Lots of errors will be obvious to experienced developers, and posting error output could be all they need to solve your problem.

5. Ask conceptual questions
No one here wants to be a part of plagiarism. Most of the people who could help you have already taken dozens of programming classes. We all understand that the assignments are difficult, but figuring these problems out is how a good programmer learns to program correctly. One sure-fire way to turn off many readers is posting your programming assignment verbatim. Just don't do it. Remember, your readers want to help you, but they don't want to help you cheat. Cheating will never help you succeed in your career, but struggling through a difficult problem will. Like I wrote previously, most of the readers have taken programming classes, so they can easily spot a homework assignment when they see one. People rarely implement their own linked-lists, stacks, or custom integer classes for work or play. No one ever really creates a virtual popsicle stand. We know homework when we see it, and few of us want to repeat problems we solved long ago. We are interested in concepts. If you are having trouble with tail-insertion in a doubly linked list, say so. Don't say you can't insert a city at the end of your travel itinerary. After all, understanding the concepts of correct programming is the goal of all our learning efforts. Many computer scientists love working through abstract, conceptual problems, so hook them with an abstract problem.

This website is a great resource for learning and experienced developers. Remember that most readers want to help you. To maximize the help you receive here, it is critical that you help your readers get to the problem. Make your title descriptive. Put your problem description and question at the beginning of your post. Only post or highlight relevant code. Post the output from your problem. Ask conceptual questions. These five methods will help you get the help you need, and it will engage your readers. Programmers come here because they want to solve problems. The best way to get help is to make yourself easy to help!

Comments
Excellent! Now all that's left is that people read this post before starting a topic...
Great post :)
This should be stickied in every coding forum...
Excellent!

Can I add two more comments to this excellent post.

When you have the first answer, you may well be asked a few more detailed questions about your problem. Please try to answer them. Even if you are certain it is not the problem [you can explain that if you like -- that will help everyone.] This lack of interactivity, seems to kill posts dead, even though the original poster (OP) replies.

Often, the act of asking the question, leads to you discovering the solution yourself. Please don't just make the thread solved, with a "found the problem", please take the trouble to tell us what you did wrong. Even if it is brain dead stupid, we may laugh, but we all have been there and done it [and in my case, I seem to continue to have BDS moments]. You certainly will earn a lot more respect for admitting the error than the "found the problem" post.

Edited 6 Years Ago by StuXYZ: n/a

Often, the act of asking the question, leads to you discovering the solution yourself. Please don't just make the thread solved, with a "found the problem", please take the trouble to tell us what you did wrong. Even if it is brain dead stupid, we may laugh, but we all have been there and done it [and in my case, I seem to continue to have BDS moments]. You certainly will earn a lot more respect for admitting the error than the "found the problem" post.

Great point. Sharing your solution may help others (that may be googling) who are experiencing the same problem. I know that when I read Linux threads looking for help on config issues, there is nothing more frustrating than finding a thread with my exact same problem that the OP marked solved with no explanation.

Comments
Rep for the main post
This article has been dead for over six months. Start a new discussion instead.