Почему мир программного обеспечения полон кодов состояния? - PullRequest
10 голосов
/ 15 марта 2010

Почему программисты когда-либо начали использовать коды состояния? Я имею в виду, я думаю, я мог бы представить, что это может быть полезно в те времена, когда текстовая строка была дорогим ресурсом. WAYYY тогда. Но даже после того, как у нас были мегабайты памяти для работы, мы продолжали использовать их. Какое возможное преимущество может быть для того, чтобы скрыть значение сообщения об ошибке или сообщения о состоянии за кодом состояния?

Ответы [ 16 ]

26 голосов
/ 15 марта 2010

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

Кроме того, коды состояния часто используются в коде и наборе:

var result = OpenFile(...);
if (result == "File not fond") {
    ...
}

Не может быть обнаружена компилятором как ошибка, где as,

var result = OpenFile(...);
if (result == FILE_NOT_FOND) {
    ...
}

Будет.

11 голосов
/ 15 марта 2010

Позволяет локализовать и изменять текст сообщения об ошибке.

8 голосов
/ 15 марта 2010

Я не думаю, что коды состояния представляют собой запутывание; это просто абстракция государства.

Широко используются целочисленные коды состояния в Конечном автомате . Наличие состояний, являющихся целыми числами, позволяет эффективному оператору switch перейти к правильному коду.

Целые числа также позволяют более эффективно использовать пропускную способность , что по-прежнему является очень важной проблемой в мобильных приложениях.

Еще один пример целочисленных кодов над строками - для сравнения. Если у вас есть похожие статусы, сгруппированные вместе (скажем, статус 10000-10999), выполнение сравнения диапазона , чтобы узнать тип статуса , является главным выигрышем. Не могли бы вы представить, как выполняются сравнения строк, просто чтобы узнать, является ли код ошибки фатальным или просто предупреждением, например:

8 голосов
/ 15 марта 2010

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

7 голосов
/ 15 марта 2010

Числа можно легко сравнить, в том числе с помощью другой программы (например, был ли сбой). Читаемые человеком строки не могут.

Рассмотрим некоторые вещи, которые вы можете включить в сравнение строк, а иногда нет:

  • Параметры кодирования
  • Диапазон поддерживаемых символов (сравните ASCII и Unicode)
  • Чувствительность к регистру
  • Акцент Чувствительность
  • Кодировка Accent (разложенные или составленные юникодные формы).

И это до того, как учесть большинство людей, которые не говорят по-английски.

4 голосов
/ 15 марта 2010

404 универсален в сети. Если кодов состояния не было, представьте, что у каждого отдельного серверного программного обеспечения есть собственная строка ошибки?

  • "Файл не найден"
  • "Файл не существует"
  • "Не удалось получить доступ к файлу"
  • «Ошибка при представлении файла пользователю»
  • «Сбой рендеринга файла»
  • «Не удалось отправить файл клиенту»
  • и т.д ...

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

3 голосов
/ 15 марта 2010

Целочисленное представление в памяти - намного более последовательная вещь, чем строковое представление. Для начала просто подумайте обо всех этих строк с нулевым символом в конце и Паскаля. Чем вы можете представить ASCII и символы от 128 до 255, которые различались в зависимости от разных кодовых страниц и заканчивались символами Unicode и их младшими порядковыми номерами с прямым порядком байтов, UTF-8 и т. Д.

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

3 голосов
/ 15 марта 2010

Компьютеры по-прежнему являются двоичными машинами, а числовые операции все еще дешевле и быстрее, чем строковые операции.

2 голосов
/ 15 марта 2010

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

Самая важная вещь в кодах состояния - это, вероятно, краткость и принятие . Две разные системы могут общаться друг с другом все, что хотят, используя цифры, но если они не согласны с тем, что означают цифры, это будет беспорядок. Краткость - еще один важный аспект, поскольку код состояния не должен быть более многословным, чем значение, которое он пытается передать. Мир может договориться об использовании

The resource that you asked for in the HTTP request does not exist on this server

в качестве кода состояния вместо 404, но это просто неприятность.

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

Может наступить день, когда мы начнем использовать изображения или даже видео, или что-то совершенно невообразимое для представления кодов состояния в сильно абстрактной форме, но мы еще не пришли. Даже для струн.

2 голосов
/ 15 марта 2010

Я работаю на мэйнфреймах, и в приложениях обычно каждое сообщение сопровождается кодом (обычно 3-4 буквы для продукта, 4-5 цифр для конкретного сообщения, а затем буква, указывающая серьезность сообщения). И я бы хотел, чтобы это было стандартной практикой для ПК.

Существует несколько преимуществ, помимо перевода (как уже упоминалось) к этому:

  1. В руководстве легко найти сообщение; как правило, программное обеспечение сопровождается руководством по сообщениям, объясняющим все сообщения (и возможное решение и т. д.).

  2. Программное обеспечение для автоматизации может реагировать на определенные сообщения в журнале определенным образом.

  3. Легко найти источник сообщения в исходном коде. Вы можете иметь дополнительные коды ошибок для каждого конкретного сообщения; в этом случае это снова полезно при отладке.

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