Recently I saw a question title of "combine 2 resultset".

I think the community deserves nicely written and formatted content. I guess this would require just ten more seconds from all of us. Sometimes I reformat others' questions to make them nicer to read.

I know this topic is subjective and surely there are people who don't care about it. But I tend to be very finicky and I like well formatted questions and answers. I know that the content I submit is far from perfect—I'm not a native English speaker, but I try my best.

Which typography glitches do you edit in questions or answers of other users? What are the most annoying style mistakes? Do you have some general layout advice?

  • 1
    Is this a question about style guidelines for for authors, or for editors?
    – einpoklum
    Oct 20, 2019 at 14:38
  • 1
    I found this question searching for stack overflow style guide. I'm frankly AMAZED that one doesn't exist. Specifically, I'm looking for recommendations for how to format external links and citations. (Like, should names of articles have quotes around them, that sort of thing.)
    – livingtech
    Apr 17, 2020 at 18:12
  • Found this question following a link that pointed it as the "Stack Overflow style guide". The accepted and top answer is focused in Stack Overflow.
    – Rubén
    Apr 21, 2023 at 7:09

7 Answers 7


Deciding whether or not to post the question

When you have decided that you need to ask your question, first you should do a thorough search on Stack Overflow to see if this question has been asked beforehand. Also, when typing a new question title in the 'Ask Question', similar titles will appear beneath it, and some questions may be very similar or even identical to yours.

So, if you find a question that is very similar to yours that has already been asked beforehand, do not post your question...for the simple reason that it will be [closed] for being an [exact duplicate].

Then, if you don't find an already-existent answer to your query, you must ask yourself one question before ultimately deciding whether or not to post your question:

Is my question here on Stack Overflow programing related?

If the answer to the above question is a no (because it only talks about hardware specifications for example), then you shouldn't post your question; reason being that, as I mentioned earlier on, it will be closed as soon as anyone above with 3K reputation points notices it.

Naming your question

The name of the question is the gateway to your question. You have to make it descriptive enough to specify your problem, but not too long that it becomes almost part of your question text.

In the title, also mention what technology, language or anything that your question is related to. For example, a title like Structuring my code won't immediately tell the people what you are referring to exactly, but something like Structuring my code in C# will give a much clearer view of what you will be talking about.

With that said, don't use titles such as Why is this not working?, or Help me with this please!!.

Oh and speaking of which, One question mark is enough
...don't do this: What are closures???

And guys, in the English Language, the first letter of a sentence is always capitalized, so apply this concept to you question title (and also to the whole text of the question).

Structuring your question

If you really can't find an answer to your query elsewhere, then open your favorite text editor, and start typing in your question. Why use a text editor and not Stack Overflow's editor? Well, you don't want to submit your question by mistake before it's complete, eh....

So when you finish writing your question, read it and correct the typos (use a spellchecker). After that, read it more carefully and correct the remaining typos once more. When you're done with the typos, check that the technical information you are asking about is correct.

When you are finished, paste your answer in the Stack Overflow editor. But the question is not ready for submission just yet.

If possible, highlight your question (ending with a question mark [?]) in bold. This is so that your question stands out in your post, more than the rest of the text.

Split your post into paragraphs.
This is a very important point, and I encounter and edit a lot of posts that look like a square (of text). Don't forget that most people scan your question, not study it, so you need to split it into multiple paragraphs, so it'll be much easier on the eyes, and much more clarified.

Formatting your question

Now, you need to, most importantly, use the Code Sample format button ({}) for code pasting. There is nothing more frustrating than trying to read code that is not formatted accordingly, especially in such a compact space.

Consider the following unformatted piece of code (JavaScript):

var aFunction = function () { var num = 9; return function () { return num += 2; }; }();

Now, take a look at the same piece of code, this time using the Code Sample formatting:

var aFunction = function () {
    var num = 9;
    return function () {
        return num += 2;

Take a guess as to which piece of code people will most likely understand?

Posting your question

When you ultimately post your question and receive answers, if one of the answers actually answers your question, mark it as answered, and this is so that (apart from the fact that the posted gets awarded for the correct answer) people will know which answer to look for if they want to see the solution to the posted question.

So you see, constructing and posting a question requires some time and effort, but that time and effort you spend will result in people answering your question as intelligently as you posted your question.

Final recap

So, just a small recap of what was said here:

  • Check, recheck and rerecheck (is that even a word?) your question before posting it
  • Use font formatting accordingly (code, question statement, and important stuff, etc.)
  • Title capitalization
  • Split your post into multiple paragraphs
  • If your question is answered, mark it as answered

There is a lot more to be said here, but the above points just came from the top of my head, and from my little experience here at Stack Overflow.

  • 1
    I don't understand the problem with having questions here that have been asked elsewhere. I think it would be great if you could find the answer to any programming on SO. How do common questions 'clutter' the site? Are you printing each one off and throwing it on your floor?
    – mr.
    Dec 31, 2008 at 18:14
  • Right, especially since Jeff Atwood, only the primary developer of the web site, said in a podcast that he wants SO to be the destination from Google.
    – BobbyShaftoe
    Jan 9, 2009 at 2:30
  • Don't forget tagging! stackoverflow.com/questions/229784/… Apr 21, 2009 at 18:36
  • @Joel Coehoorn: New location is: meta.stackexchange.com/questions/18878 Jan 31, 2010 at 18:53
  • 1
    Re "And guys, in the English Language, the first letter of a sentence is always capitalized" I'm not sure that's true. For example "iPhones are often considered overhyped" Apr 26, 2014 at 8:38
  • "Structuring my code in C#" How is that better? The C# should be a tag.
    – bjb568
    Apr 26, 2014 at 8:53

As an example (real question on Stack Overflow):


serialport parameter in java

Hi, i'm beginner in java,i'm reading data from port thr serail port,i got serialPort.setSerialPortParams(9600, SerialPort.DATABITS_ 8, SerialPort.STOPBITS_ 1, SerialPort.PARITY_ NONE); what is the meaning of 9600,DATABITS_8,STOPBITS_1 AND PARITY_NONE.


Serial port parameter in Java

Hi, I'm a beginner in Java. I'm reading data from the serial port. I got

   9600, SerialPort.DATABITS_8, 
   SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 

What is the meaning of 9600, DATABITS_8,STOPBITS_1 and PARITY_NONE?

I changed following things here:

  • Capitalization at the beginning of a sentence
  • Capitalization of "i" and proper names ("java")
  • Added missing spaces after punctuation
  • Grammar: "i'm (a) beginner"
  • Corrected typos: "thr", "serail"
  • Code Sample formatting
  • Added missing question mark
  • 2
    I'm still looking for the formatting guide for StackOverflow. I assume we aren't supposed to do all this using HTML markup, but I haven't found the guide to SO markup yet. Should there be a pointer here? (Even if the answer is "use html", there should be a writeup of how to markup code, and other idiosyncrasies.
    – PanCrit
    Apr 25, 2009 at 18:40

I'll edit spelling mistakes, poor grammar, poor formatting (lists, code blocks), poor titles... just about anything really, as long as I'm not changing what the question is about.

When closing a question as a duplicate I've noticed a few styles, but I don't edit these:

  • Leave the duplicate URL in a comment
  • Add the URL to the bottom of the question (my preferred style)
  • Add the URL to the top of the question

I also (almost) never edit answers - I'll leave a comment instead.

Just out of interest, are you a writer for The Sun? :)


Some things to do and to not do.

  1. Don't begin an answer with "as others have said". Each answer is independent. And independently voted up or down -- there's no inherent order to the answers. If yours is good, but entered later, it will be voted up leading to the curious problem of the top answer referencing lower-ranked answers.

    • Please quote the other answers

    • Or link to the other answers.

  2. Don't QFT another answer. Quoting for Truth leads to duplicate answers.

    • Please upvote the answer with a comment.
  3. Don't expand your question via an answer. If you want to respond to an answer, either

    • Comment on the answer

    • Update your question

    This is not threaded email -- the order of the questions and answers changes. Your non-answer will get down-voted, fall to the bottom and disappear.

  • I don't see the problem with a higher voted answer referencing a lower voted answer. That also assumes that there isn't anything like the fastest gun in the west problem. Answers beginning with "As others have said" are probably just adding bits and pieces rather than attempting to repeat other answers (I'm not keen on the repetition on this set of sites). Apr 7, 2010 at 1:42

Most any editing is fair game though you should try to respect the original author's style choices lest you spark an edit war over brace style or something. :) Also, be conservative about edits that clarify questions since you could inadvertently make some of the answers sound stupid or pedantic or confused or such. When in doubt I'll add an explicit "ADDED:" to the question so it's clear that the answerers may not have seen the addendum. On the other hand, Stack Overflow questions are meant to be like a definitive collection of mini-essays on a topic for posterity, so don't try to maintain a strictly faithful dialog either. Save that for the comments (which are also helpful to alert answerers to changes in the question).

The brace style edit war was hypothetical (I hope), but here's a contentious answer to your question about what edits are annoying: I find it annoying when people contort question titles to be in the form of a question. Like "How can I create a regular expression to parse names?" instead of just "Regular expressions to parse names." Get rid of the filler words in the title to make more room for keywords (perhaps "Regular expression to parse out first and last names."). It's still clear that you're asking how to create said regular expression, and you can use the body of the question to make the actual question more explicit.

  • I'd be sorely tempted to parse out the 'out' in the suggested rewrite of the title :D Dec 26, 2008 at 2:47
  • Ha, yeah, "parse out" may not parse as proper English. :) Feel free to fix it!
    – dreeves
    Dec 26, 2008 at 18:52

I think it's important for a post on Style to let people know that there is a special help page for Markdown syntax.


Here I describe my answer style that has gradually evolved trough the years. I decided to write it down as it solidified and as I noticed some patterns.

Markdown generics

I use my style guide described at: http://www.cirosantilli.com/markdown-style-guide/ It is too long to reproduce here. This guide will focus only on SO specifics.

Use bold for title-like structs




**Another subsection**


Don't use headers as they are too large, and don't generate any link IDs anyways...

Don't use bold anywhere else, otherwise readers will have a time finding the subsection titles.

Start every answer with a title

Summarizing the key part of the answer:

**Minimal runnable example**

Theory and experiment

The perfect answer often contains both:

  • experiments: concrete examples you have run to verify that you understood the theory

  • theory: for most programming questions, this means a quote from canonical standards, documentation, or source code

    Provide the exact version of the documentation, ideally with a link to it, and quote the most relevant paragraphs in the answer.

The experiment should come first, that is the better way to teach something to humans.

Extremely concrete experiments

If the answer contains an experiment, provide:

  • full runnable code
  • full commands used
  • expected output

and only then start explaining why the expected output happened.

Tested with

If you did any experiments, add a "Tested with:" section at the end of your answer, so that others will know how to reproduce your results.

This should include:

  • your distro version

  • the version of key utilities used in the answer

    While this is implied from Ubuntu version for example, it still saves readers some time.


Tested on Ubuntu 18.04, GCC 8.2.0.

It is true that Ubuntu patchlevel versions e.g. 18.04.2 may change those versions further, and you can also get even more precise package information from dpkg -l e.g.:


but I think it is reasonable to omit this level of detail as it is likely too much for most users.

If you have tested different sections with different OSes, add the tested with line for each section instead of at the end of the answer.


Add a colon to the previous paragraph of every code block or terminal excerpt:

Run this command:

    echo asdf



If your reference code is:

  • medium sized, inline it and also add it to your GitHub / GitLab / etc. and link to it to properly version control the code and review pull requests.

    E.g., link to your GitHub upstream after the code as:

        // My medium large code
    [GitHub upstream](https://github.com/myusername/myproject/tree/<sha>/path/to/myfile).
  • very large: omit it from the answer, and just link to upstream.

    Stack Overflow has a 30k character answer size limit, so that is an absolute upper limit.


Represent files and their names as:


    int main(void) {
        return 1;


    int myvar = 0;

The most important file of each example should be called main.extension, e.g. main.c, unless there is a more important convention on the language, e.g. index.html.


If input / output images are involved in the answer, provide them.

Relevant images are fun and intuitive!

Videos are also good! They can be represented with GIFs, see:

If a diagram would help, also consider some ASCII art.

Standard quotes

Like this:

The [C11 N1570 standard draft](http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf) 6.2.5 "Some very important section" says:

> 6 Useless quote that no one understands.

6.2.5 "Another not so important one" says:

> 9 Yadayada yup dup.

So note:

  • the first quote links to the standard with it's name
  • section numbers are plain
  • section titles corresponding to numbers are quoted
  • says: then > quote
  • following quotes don't need to re-link to the same standard, just section number plus name

Intersperse paragraphs with lists, code blocks and other block elements

Having a huge sequence of plain paragraphs, or God forbid, one huge paragraph, makes text very boring to look at.

Instead, intersperse block elements throughout your text.

This just makes everything more pleasing to look at, and easier for the eye to know where you are.

For example, instead of creating a list in a paragraph as in:

To become a good programmer you have to code, read other people's code, and use a debugger.

could be used to add a block element as:

To become a good programmer you have to:

- code
- read other people's code
- use a debugger

For the same reason, every code block that is more than one word can be used as a block rather than inline if you feel that a block would look nice.

Beautiful text is not just text. Beautiful text is half text, and half ASCII art. There is almost a texture, or tempo, to it.

Question title style guide

I have summarized my recommended question title style at: How do I write a good title?


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .