The computer (or more accurately the compiler) doesn't really care at all what number base you use in your source code. Most commonly used programming languages support bases 8 (octal), 10 (decimal) and 16 (hexadecimal) directly. Some also sport direct support for base 2 (binary) numbers. Specialized languages may support other number bases as well. (By "directly support", I mean that they allow entry of numerals in that base without resorting to mathematical tricks such as bitshifting, multiplication, division etc. in the source code itself. For example, C directly supports base-16 with its
0x number prefix and the regular hexadecimal digit set of 0123456789ABCDEF. Now, such tricks may be useful to make the number easier to understand in context, but as long as you can express the same number without them, doing so - or not - is only a convenience.)
In the end, however, that is inconsequential. Let's say you have a statement like this following:
int n = 10;
The intent is to create an integer variable and initialize it with the decimal number 10. What does the computer see?
i n t n = 1 0 ;
69 6e 74 20 6e 20 3d 20 31 30 3b (ASCII, hex)
The compiler will tokenize this, and realize that you are declaring a variable of type
int with the name
n, and assign it some initial value. But what is that value?
To the computer, and ignoring byte ordering and alignment issues, the input for the variable's initial value is
0x31 0x30. Does this mean that the initial value is 0x3130 (12592 in base 10)? Of course not. The language parser must keep reading the file in the character encoding used, so it reads
0 followed by a statement terminator. Since in this language base 10 is assumed, this reads (backwards) as "0 ones, 1 tens, end". That is, a value of 10 decimal.
If we specified a value in hexadecimal, and our language uses
0x to specify that the following value is in hexadecimal, then we get the following:
i n t n = 0 x 1 0 ;
69 6e 74 20 6e 20 3d 20 30 78 31 30 3b (ASCII, hex)
The compiler sees
0x (0x30 0x78) and recognizes that as the base-16 prefix, so looks for a valid base-16 number following it. Up until the statement terminator, it reads
10. This translates to 0 "ones", 1 "sixteens", which works out to 16 in base 10. Or 00010000 in base 2. Or however else you like to represent it.
In either case, and ignoring optimizations for simplicity's sake, the compiler allots enough storage to hold the value of an
int type variable, and places there the value it read from the source code into some sort of temporary holding variable. It then (likely much later) writes the resulting binary values to the object code file.
As you see, the way you write numerical values in the source code is completely inconsequential. It may have a very slight effect on compile times, but I would imagine that (again, ignoring such optimizations such as disk caching by the operating system) things like random turbulence around the rotating platters of the disk, disk access times, data bus collisions, etc., have a much greater effect.
Bottom line: don't worry about it. Write numbers in a base that your programming language of choice supports and which makes sense for how the number will be used and/or read. You spent far more time reading this answer than you will ever recover in compilation times by being clever about which number base to use in source code. ;)