Почему мир программного обеспечения полон кодов состояния?

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

10
задан 3 revs, 2 users 100% 9 May 2010 в 17:45
поделиться

16 ответов

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

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

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

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

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

будет.

26
ответ дан 3 December 2019 в 13:11
поделиться

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

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

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

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

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

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

2
ответ дан 3 December 2019 в 13:11
поделиться

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

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

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

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

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

2
ответ дан 3 December 2019 в 13:11
поделиться

Очень помогает простой и универсальный метод определения статусов.В то время как строки могут легко набираться по-разному в зависимости от диалекта, а также могут иметь грамматические изменения, числительные не имеют грамматического форматирования и не меняются с диалектом. Существует также проблема с хранением и передачей, строка больше и, следовательно, требует больше времени для передачи по сети и хранения (даже если это несколько тысячных долей миллисекунды). Из-за этого мы можем назначать номера в качестве универсальных идентификаторов для статусов, поскольку они могут передаваться быстрее и точнее, а программы, которые их читают, могут идентифицировать их, как они хотят (будучи многоязычными).

Кроме того, легче читать с помощью вычислений:

switch($status) {
case '404':
echo 'File not found!';
break;
case '500':
echo 'Broken server!';
break;
}

и т. Д.

0
ответ дан 3 December 2019 в 13:11
поделиться

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

8
ответ дан 3 December 2019 в 13:11
поделиться

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

3
ответ дан 3 December 2019 в 13:11
поделиться

Как насчет обратной совместимости с 30+ летними библиотеками программного обеспечения? В конце концов, часть кода все еще пишется на C ...

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

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

2
ответ дан 3 December 2019 в 13:11
поделиться

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

0
ответ дан 3 December 2019 в 13:11
поделиться

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

Машинам также легче понимать коды, поскольку вы можете назначать классы ошибок диапазону чисел. Например, 1–10 - это проблемы ввода / вывода, 11–20 - это дБ и т. Д.

2
ответ дан 3 December 2019 в 13:11
поделиться

Что ж, при разговоре с клиентом по телефону номер намного лучше, чем строка, а строка может быть на многих разных языках, на которые число не может, попробуйте поискать в Google текст ошибки, скажем, на шведском языке, а затем попробуйте поискать его в Английский угадай, где ты получишь лучший результат.

2
ответ дан 3 December 2019 в 13:11
поделиться

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

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

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

4
ответ дан 3 December 2019 в 13:11
поделиться

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

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

3
ответ дан 3 December 2019 в 13:11
поделиться

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

Большое применение целочисленные коды состояния находят в конечных автоматах. То, что состояния являются целыми числами, позволяет эффективному switch оператору переходить к правильному коду.

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

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

8
ответ дан 3 December 2019 в 13:11
поделиться

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

11
ответ дан 3 December 2019 в 13:11
поделиться

Коды состояния уникальны, а строки могут быть нет. Существует только один код состояния, например «213», но может быть много интерпретаций, например, «файл не найден», например «Файл не найден», «Файл не найден!», «Datei nicht gefunden», «Файл не существует» ....

Таким образом, коды состояния максимально упрощают информацию!

2
ответ дан 3 December 2019 в 13:11
поделиться

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

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

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

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

7
ответ дан 3 December 2019 в 13:11
поделиться
Другие вопросы по тегам:

Похожие вопросы: