Declaring Variables

Question

Say you have a variable called hotelPropertyNumber. The contents will always be a number but normally be used as a string. Would there be anything "wrong" with declaring it as a string so that you don't have to continually convert it to a string....or is that a bad programming habit?

Thanks.

Answer 1

Never say always. It may not always be represented by digits. 14 may, for instance, be subdivided into 14a and 14b. Or 21 and 22 may be merged into 21-22. It's more likely than doing arithmetic with them.

Look at street addresses, which usually start out with the intention of being numerical. (Pretty close analogy, too.)

Answer 2

Igor Krovokon already said it, but I wanted to elaborate a bit.

Why do you think the contents of a hotel number is a number? "12" is not a number. It is a string containing a couple of digits. You can't take the square root of room #153, but you can do it with the number 153.

A hotel room number does not behave as a number. A number is a mathematical concept, and can be represented textually in a lot of different ways. 14 could be written as XIV in roman numerals, "fourteen", or 0xfe in hex, or 11111110 in binary. But the hotel staff is likely to give you a very odd look if you ask for "room one-one-one-one-one-one-one-zero."

Hotel room numbers are not mathematical numbers, so they should not be represented as integers.

Are they string then? Yes, more or less, but they do have a few additional constraints, as you noticed.

Not every string is a valid hotel number. "14" is good, but "Watermelon" is not.

So ideally, it should be represented as an abstract data type which wraps a string, and ensures that no non-digits exist in the string.

In practice, of course, you're unlikely to run into many problems if you take the simple way out though, and represent room numbers as either ints or strings. But the best design would be one that ensured that room numbers behave as room numbers. Neither strings or ints do that.

Answer 3

It's not a bad habit per-se, but it could lead to trouble later on.

Speaking now from personal experience: I used to be a big fan of storing numerical values that were always going to be used as a string in string variables. I mean, why not, right? Saves you all that tedious casting and whatnot, and you can get on with the real meat of the problem. (Which, of course, is deciding what to order for lunch.)

Then, I spent the better part of a day trying to figure out why the live system was throwing all kinds of insane exceptions. Turns out that "1" I was looking at in the data was really a lower case "l".

And then, as they say, I became enlightened.

(Of course, this can really change based on what language you're in. In something like Java, a few lines worth of class definition solve all these issues. In Python or Perl, the question doesn't even mean anything - the language just "gets it right". Well, for some definition of "right", anyway.)

Answer 4

You can always make a public "HotelPropertyNumber()" function which returns the number as a string, but the int is still kept under the covers.

If you decide you really don't need the int under the covers, HotelPropertyNumber() can just return the private string.

Answer 5

Always store your information in its simplest form. In this case, an integer. Convert it to a string when necessary. Nearly all languages make this almost painless, especially for an integer to a string.

A good example of this was in the StackOverflow Podcast #58, when Jeff stored the title's HTML in the database and not just the title by itself. This caused lots of problems when he wanted to add functionality later and display that title where HTML wasn't needed.

ChrisW also brings up a great point that doing this asserts type safety. I thought that was important enough to note.

Answer 6

In some languages you can create a user-defined type such as "class HotelPropertyNumber", which:

• Supports exactly the methods you need
• May store its data internally as a string
• Can validate (in its constructor) that its value has a number-like syntax
• Can't be confused with other number and/or string type instances which aren't HotelPropertyNumber instances.

Answer 7

Would it make sense to change the name to hotelPropertyIdentifier? That might avoid all the connotations of calling someting a number.

Answer 8

I disagree with Eric.

There are no "Always" rules in development.

If you are using this variable primarily as a string, then it makes more sense to store it as a string, and lose the "number" from the variable name.

If you are doing more numerical operations on this variable, then it's a number, and should be stored as an numerical value, and converted a string for use as a string.

Answer 9

It depends what you want to do with them.

You are probably never going to perform arithmetic on them, but how about sorting? Integers will sort in a different way than strings will. Do you want them to be 1, 10, 2, etc.? If not, then use integers or a special sort method.

On the other hand, using strings will allow for more types of "numbers" later. "10090A", for example. And there won't be any problems with overflow as can happen with integers.

Answer 10

A number is a mathematical object used in counting and measuring. If you use your hotelPropertyNumber for counting, i.e. apply any arithmetic operations to it, it is number and should be stored as a numeric type.

If not, then it is not a number; it is a string.

Answer 11

Nope not necessarily wrong. But you might want to consider renaming the variable to reflect that it is a string. I don't think there is a simple answer to whether you should keep it a number or converting it to a string. It depends on the situation. If you choose to store it as an integer in your application and have to convert it to a string 1000 times in your code, then it might be worth doing the conversion to a string one time. You'd have to consider the trade offs depending on the situation.

Answer 12

I agree with @Eric. You'll find that if you declare it as string you'll make mistakes either parsing it as int, or enforcing it as int. Just use an int.