Numeric \$\neq\$ Decimal
Your code (and perhaps the exercise description) seems to confuse decimal with numeric. An integer is an abstract mathematical concept. A binary representation of an integer is one of many possible ways to represent its value. Decimal representation is just another way. So is spelling out the English word (eg “thirteen”).
Talking about an
int as “decimal” is wrong. Internally, it is not represented in decimal but binary form. But what you probably care about is not the internal representation but the value. That is, what you want is not a function
toNumber that gives you the numeric value of an integer's string representation in binary format.
On the other hand, if the exercise is to be taken literally and you're really supposed to produce a “decimal” form, then you should probably
return a string of digits from
9 that represents the same value as the input string. I'm not sure whether this is expected from you and having a “binary → decimal” function would also be poor design as you would then need \$n^2\$ functions to convert between \$n\$ representations when you could have done with \$2n\$ using two families of “some representation → numeric value” and “numeric value → some representation” functions. (And \$n\$ could quickly grow considerably if you think about binary, octal, decimal, hexadecimal, …)
If your function is given invalid input, it
returns 0. While there is infamous precedence for this in the C standard library, it is nothing to feel good about. For the users of your function, it probably matters whether your function successfully parsed
"0" to 0 or failed to parse nonsensical input. Using a plausible result to indicate error is a bad idea in general. You have a few options to report errors in a more useful way. (In order of my personal preference.)
throw an exception (eg
NumberFormatException) on error.
Good because it cannot be ignored and doesn't clutter client code where failure is not expected. Not so good if you expect many failures because
catching exceptions is relatively expensive and verbose.
return type to
Good if you expect many failures because it better communicates that failure is a normal result. Not so good for performance as you have to allocate two objects and the function becomes a little more verbose to use in cases where failure is not expected.
Since you're not supporting negative numbers, you could use –1 to unambiguously indicate error.
Best option for performance. Poor option for usability as errors can easily be ignored by accident. It also paints you into a corner where you cannot enhance your function later to also support negative numbers.
return type to
Integer and use
null to indicate error.
Poor man's version of using an
Optional. Less performance overhead as only a single object has to be allocated (and that might not be needed since the JVM caches
Integers) but also less clear about your intent.
Unit Tests for Corner Cases
I would add unit tests for the corner case
"0" (you already have
"1") as well as
"1111". (The four digits are arbitrary, the point is to test a few repetitions of the same digit.)
If you're serious about the quality of your implementation, also test
Integer.MAX_VALUE (that is, a string of 31 consecutive
1s preceded by zero or more leading
0s). And as we are at it, think about what your function should do if it is given inputs that are too large to be represented in an