2009-06-19 3 views
2

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

Спасибо.

ответ

6

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

Если нет, то это не a number; это строка.

+0

Никогда не думал о том, чтобы приблизиться к этому. Переменная никогда не будет использоваться в арифметических операциях. Это действительно просто идентификатор, который использует большая сеть отелей, чтобы отличить установки системы управления имуществом. Я видел и слышал, как это называлось как «ID» и «number». Последнее - это то, что застряло, так как это то, что я слышал в первую очередь. В любом случае идентификатор является одной из переменных, которые передаются некоторым методам/функциям WCF в моем приложении. – Lenard

3

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

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

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

+2

Иногда стоит создать определенный пользователем тип, например класс HotelPropertyNumber, просто чтобы отличить его от других строк и чисел и, возможно, выполнить некоторую проверку синтаксиса в конструкторе и помочь сделать код более самодокументируемым и безопасным по типу и т. д. – ChrisW

+0

@ Крис: Тип безопасности здесь такой же большой проблемой, как и все. Отличное предложение. – Eric

+1

Это также помогает сделать его надежным на будущее: поскольку он фактически хранится как число или как строка, становится частным элементом реализации класса. – ChrisW

0

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

0

Я согласен с @Eric. Вы обнаружите, что если вы объявите его как строку, вы допустите ошибки, либо разобрав его как int, либо принудительно применяя его как int. Просто используйте int.

2

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

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

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

+1

Сортировка - хороший pro для целых чисел, а проблемы с ведущим-0 - хорошие профи для строк. –

0

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

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

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

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

+0

Я думаю, что всегда хранить что-то в его простейшей форме имеет смысл, и я не думаю, что это плохой совет. Уступки немного удобнее, принося в жертву гибкость для будущего развития - это ненужный уровень сложности, ИМХО. Я был сожжен слишком много раз, воспользовавшись ярлыком, подобным этому, и по этой причине я не могу рекомендовать резку углов. – Eric

+0

Простейший вариант зависит от использования. Мое возражение семантическое. Говорить, что вы должны «всегда» делать что-то таким образом, в разработке программного обеспечения есть красный флаг. Почему вы всегда должны хранить числовое значение как целое число? Если он используется только как строка, то почему нужно постоянно оплачивать накладные расходы процессора для преобразования в строку? Вот почему я не согласен с вами. – Alan

0

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

+0

Это на самом деле очень хорошее имя. Я также рассмотрел hotelPropertyCode, но мне нравится ваш лучше. – Lenard

6

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

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

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

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

+0

На самом деле у меня есть функция GetHotelPropertyNumber(). Когда я представил свой вопрос, я думал о том, как передать номер свойства моим методам. В любом случае, много хороших ответов на мой вопрос. – Lenard

-1

Это не плохой привычка per-se, но это может привести к проблемам позже.

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

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

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

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

+1

Конечно, одним из других разработчиков было указано, что у нас были проблемы с безопасностью, это была проблема * font *. Мы проигнорировали его. И затем переключился на лучший шрифт. –

2

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

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

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

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

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

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

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

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

0

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

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

Смежные вопросы