In our documentation, we write binary numbers like this: 1010

But we write hexadecimal numbers like this: 0xABAB

Now, according to the GCC compiler conventions:

  • Numbers are normally written in decimal.
  • Binary numbers are preceded by 0b.
  • Hexadecimal numbers are preceded by 0x.

But in my mind, writing binary numbers as 0b1010 just looks wrong. But I can't tell my writers "don't do it because it looks wrong", especially because we write the hex numbers with a 0x prefix.

Are there any programmers out there who can weigh in on why I shouldn't use the 0b prefix? I need reinforcements :).

  • 1
    I don't see anything wrong with 0b. Either for 0o.
    – rus9384
    Nov 14, 2018 at 22:09

5 Answers 5


If you indicate hex as 0x, it's consistent to indicate binary as 0b, and inconsistent to write binary numbers without a prefix. That's not specific to the compiler, those are widely-used conventions (albeit not a universal standard).

  • Right, that's pretty much what I thought - but part of me still resists seeing binary with an 0b in front of it.
    – Yoel
    Feb 1, 2018 at 7:03

As somewhat alluded to by Chenmunka, if your documentation is generally in the context of a specific programming language and/or compiler, it is probably best to stick to what is required by those. However, I think this is also somewhat dependent on why the numbers are appearing in your documentation.

If you are referencing these numbers as something would directly appear in code, you should definitely use the language's standard format for the base you're using. On the other hand, if the documentation is simply bringing up the binary representation to explain a feature or illustrate a point, I think this is less necessary, so long as it is very clear that he number is binary.

The reason for the prefixes in code is that the compiler cannot know what base you're using without a hint. 1011 is valid decimal, hexadecimal, octal, and binary, so a prefix is required to denote which is being used. In your documentation you may be introducing the number with an appropriate context that makes this unnecessary:

Assuming the following binary representation of [foo]:


We can see that it has the properties [bar] and [baz].

In this case I think the 0b prefix would be unnecessary and possibly even make the documentation less readable, depending on the audiences familiar with programming languages.

In circumstances where large amounts of your documentation may have numbers like this, especially if the base may change depending on the context, introducing the notation early on (e.g. "We will be using the prefix "0b" to denote binary sequences and "0x" to denote hexadecimal sequences") might help as well.


Traditional mathematical notation would be to use a subscript suffix containing the base of the number in decimal, e.g.:

The value 101111012 is equivalent to BD16.

This may or may not be appropriate for your use, depending on how familiar your readers are likely to be with this notation, and what purpose they will be reading it for. As suggested elsewhere, if the readers are likely to be using the documentation for work in a specific language then following the conventions of that language may well be the best bet.


People will type things the way you write them in the documentation. People are looking for concrete instructions on what to do, not philosophical discussion of the working of the system.

So, enter them in the documentation the way people should enter them in the product.

  • 1
    These aren't instructions that readers need to type - they are values and addresses for the registers that are at the heart of our systems.
    – Yoel
    Feb 1, 2018 at 7:04

I like more the Intel method: 10010b and 1f4dh. On the other hand, you should follow the convention that your reader are supposed to use (e.h. if you are describing a C API, you should use C convention.

On generic documentation, probably I would be more verbose, Something like 10010 bin, maybe with a mouse-over bubble which show the value in decimal and hexadecimal.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.