Labels and Best Practices

[gl00mie]

А мне кажется, очень стрёмно делать ветвления в коде на основе текстовых строк - метками ли они задаются или нет. Фактически тут в код зашит строковый литерал, который в зависимости от языка, настроенного у пользователя, может быть подменен ядром на другой строковый литерал. Кто-то может залезть и поменять текст метки, потому что ему больше нравится другой вариант, и чего, все сломается?
Текстовые строки надо преобразовывать в Enum, если не преобразовалось - слать куда подальше, а если преобразовалось, то в коде уже принимать решения на основе значения Enum (в switch), включая обработку значений, которые не предусмотрены в коде (в default - выбрасывать ошибку). Если строк может быть очень много для Enum и они могут произвольно меняться, то можно настроечную таблицу завести и логику уже привязывать к найденной записи настроечной таблицы... Строковые литералы приемлемы, если они в макросах зашиты (скажем, названия элементов XML-схемы), а с метками их сравнивать - нафиг...

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

[wojzeh]

ну, так я о том и написал, что BP не разрешает делать такие трюки с метками!

кстати говоря, а как проверить, что мы при импорте из текстового поля получили существующее значение перечисления (enum)?

как известно, первым идёт значение 0, оно же выбирается по умолчанию. как быть?

вот это вот "если не преобразовалось" - это как?

[S.Kuskov]

Цитата:

Сообщение от wojzeh

а как проверить, что мы при импорте из текстового поля получили существующее значение перечисления (enum)?

как известно, первым идёт значение 0, оно же выбирается по умолчанию. как быть?

Вариант 1.
При создании enum не присваивать ни одному из его значений код 0. Значение по умолчанию, все равно останется ноль, т.к. enum - это int, но теперь оно не будет совпадать ни с одним из его реальных значений.

Вариант 2. Перед использованием явно проинициализировать переменную enum несуществующим значением, например отрицательным.

[belugin]

Цитата:

Сообщение от S.Kuskov

Вариант 1.
При создании enum не присваивать ни одному из его значений код 0. Значение по умолчанию, все равно останется ноль, т.к. enum - это int, но теперь оно не будет совпадать ни с одним из его реальных значений.

Вариант 2. Перед использованием явно проинициализировать переменную enum несуществующим значением, например отрицательным.

Вариант 3 - добавить в enum значение с 0 под названием None

[wojzeh]

Цитата:

Сообщение от belugin

Вариант 3 - добавить в enum значение с 0 под названием None

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

[belugin]

Цитата:

Сообщение от wojzeh

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

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

Можно еще хранить признак корректности импорта где-то еще - в другом поле или даже в другой таблице. Но лучше не декларировать что в поле может быть только No и Yes и писать туда 3.145928

[wojzeh]

Цитата:

Сообщение от belugin

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

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