Объявление переменных - PullRequest
2 голосов
/ 20 июня 2009

Скажем, у вас есть переменная с именем hotelPropertyNumber . Содержимое всегда будет числом, но обычно используется как строка. Будет ли что-то «неправильным» в объявлении строки как строки, чтобы вам не приходилось постоянно преобразовывать ее в строку… или это плохая привычка программирования?

Спасибо.

Ответы [ 12 ]

6 голосов
/ 20 июня 2009

В некоторых языках вы можете создать пользовательский тип, такой как "class HotelPropertyNumber", который:

  • Поддерживает именно те методы, которые вам нужны
  • Может хранить свои данные в виде строки
  • Может проверить (в своем конструкторе), что его значение имеет числовой синтаксис
  • Не может быть перепутано с другими экземплярами числа и / или типа строки, которые не являются экземплярами HotelPropertyNumber.
6 голосов
/ 20 июня 2009

Число - это математический объект, используемый для подсчета и измерения. Если вы используете ваш hotelPropertyNumber для подсчета, то есть применяете к нему любые арифметические операции, он равен числу и должен храниться как числовой тип.

Если нет, то не является числом; это строка.

3 голосов
/ 20 июня 2009

Всегда храните вашу информацию в простейшем виде. В этом случае целое число. При необходимости преобразуйте его в строку. Почти все языки делают это почти безболезненным, особенно для целого числа в строку.

Хороший пример этого был в StackOverflow Podcast # 58 , когда Джефф сохранял HTML-код заголовка в базе данных, а не только сам заголовок. Это вызвало много проблем, когда он захотел добавить функциональность позже и отобразить этот заголовок там, где HTML не нужен.

ChrisW также замечает, что при этом утверждается тип безопасности . Я подумал, что это достаточно важно, чтобы отметить.

2 голосов
/ 20 июня 2009

Игорь Кровоконь уже сказал это, но я хотел бы уточнить.

Почему вы думаете, что номер отеля - это номер? «12» - это не число. Это строка, содержащая пару цифр. Вы не можете взять квадратный корень из комнаты # 153, но вы можете сделать это с номером 153.

Номер в гостиничном номере не ведет себя как номер. Число является математическим понятием и может быть представлено в тексте множеством разных способов. 14 можно записать как XIV римскими цифрами, «четырнадцать», или 0xfe в шестнадцатеричном формате, или 11111110 в двоичном. Но персонал отеля, скорее всего, будет выглядеть очень странно, если вы попросите "номер один-один-один-один-один-один-один-ноль".

Номера гостиничных номеров не являются математическими числами, поэтому их не следует представлять в виде целых чисел.

Они струны тогда? Да, более или менее, но у них есть несколько дополнительных ограничений, как вы заметили.

Не каждая строка является действительным номером отеля. «14» - это хорошо, а «Арбуз» - нет.

Так что в идеале он должен быть представлен в виде абстрактного типа данных, который переносит строку и гарантирует, что в строке не существует никаких цифр.

На практике, конечно, вы вряд ли столкнетесь с множеством проблем, если примете простой выход и представите номера комнат как целые или строковые значения. Но лучшим дизайном будет тот, который гарантирует, что номера комнат ведут себя как номера комнат. Ни строки, ни целые числа не делают этого.

2 голосов
/ 20 июня 2009

Зависит от того, что вы хотите с ними сделать.

Вы, вероятно, никогда не собираетесь выполнять арифметику с ними, но как насчет сортировки? Целые числа будут сортироваться не так, как строки. Вы хотите, чтобы они были 1, 10, 2 и т. Д.? Если нет, то используйте целые числа или специальный метод сортировки.

С другой стороны, использование строк позволит использовать больше типов «чисел» позже. «10090А», например. И проблем с переполнением не будет, как это может случиться с целыми числами.

0 голосов
/ 20 июня 2009

Никогда не говори всегда. Это не всегда может быть представлено цифрами. 14, например, может быть подразделен на 14a и 14b. Или 21 и 22 могут быть объединены в 21-22. Это более вероятно, чем делать с ними арифметику.

Посмотрите на адреса улиц, которые обычно начинаются с намерения быть числовыми. (Довольно близкая аналогия тоже.)

0 голосов
/ 20 июня 2009

Само по себе это не плохая привычка, но в дальнейшем это может привести к неприятностям.

Говоря теперь из личного опыта: я был большим поклонником хранения числовых значений, которые всегда собирались использовать в качестве строки в строковых переменных. Я имею в виду, почему бы и нет, верно? Это избавит вас от всего этого утомительного кастинга и еще много чего, и вы сможете справиться с настоящей проблемой. (Что, конечно, решает, что заказать на обед.)

Затем я провел большую часть дня, пытаясь выяснить, почему живая система выдает всевозможные безумные исключения. Оказывается, что «1», на который я смотрел в данных, действительно была строчной буквой «l».

А потом, как говорится, я стал просветленным.

(Конечно, это действительно может измениться в зависимости от того, на каком языке вы находитесь. В чем-то вроде Java, несколько строк определения класса решают все эти проблемы. В Python или Perl вопрос даже ничего не значит - язык просто «делает это правильно». Ну, в любом случае, для некоторого определения «правильно», в любом случае.)

0 голосов
/ 20 июня 2009

Вы всегда можете сделать публичную функцию "HotelPropertyNumber ()", которая возвращает число в виде строки, но int все еще хранится под прикрытием.

Если вы решите, что вам действительно не нужен int под обложками, HotelPropertyNumber () может просто вернуть приватную строку.

0 голосов
/ 20 июня 2009

Имеет ли смысл изменить имя на hotelPropertyIdentifier? Это могло бы избежать всех коннотаций вызова некоторого числа.

0 голосов
/ 20 июня 2009

Я не согласен с Эриком.

В разработке нет правил "Всегда".

Если вы используете эту переменную главным образом в виде строки, то имеет смысл сохранить ее как строку и потерять «число» из имени переменной.

Если вы выполняете больше числовых операций с этой переменной, то это число, и оно должно быть сохранено как числовое значение и преобразовано в строку для использования в качестве строки.

...