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

У меня есть фрагмент кода PL/SQL, который выглядит примерно так:Избегайте жесткое кодирование в случае, если оператор с несколькими условиями

IF l_order = 'Cancelled At Order Stage' OR l_order = 'Stopped at Billing Stage' THEN 
    Do something 
END IF; 

IF l_type = 'Internal' OR l_type = 'Contracted' THEN 
    Do something else 
END IF;

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

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

источник

2015-02-13 Andrew Martin

Вы можете параметризовать строки в локальные переменные, такие как 'l_cancelled: = 'Отменено на этапе заказа';' и держать их всех в верхней части вашей функции/proc/package. – mmmmmpie

@mmmmmpie: Это была моя мысль. Вы бы всегда рекомендовали сделать это, чтобы избежать жесткого кодирования, даже если есть только одна переменная? Во-вторых, не могли бы вы всегда держать их в верхней части функции/пакета, или вы бы поставили их чуть выше определенного блока, который им нужен, поэтому они никогда не объявляются/не создаются, если это необходимо? –

Это зависит от того, насколько параметризованным вам нравится ваш код. Я видел, как архитекторы требуют таких вещей, как 'char comma = ',';' поэтому YMMV полностью на этом. Во-вторых, предпочтение разработчика/архитектора в том, где вы их определяете. Помогает ли PL/SQL, где вы их заполняете? Нет, но читаемость может. Если мне нужно идти за вами и работать над вашим кодом, я бы предпочел бы, чтобы это строковое объявление либо a) хранилось в таблице в самом DB (например, в поле flex), либо b), заполненном в самом начале. В-третьих, у вас не должно быть переменных, объявленных и никогда не используемых, если вы обнаружите, что в этой ситуации вы слишком гранулированы. – mmmmmpie

$A := Hard-coding 
$B := bad 
$C := weigh 
$D := advantage 
$E := configurability 
$F := cost 
$G := reduced readability

$ А не всегда $ B. Вы должны $ C $ D $ E от $ F $ G.

People can only keep a small number of new variables in their head at once. Это зависит от вас, чтобы решить, что в вашей системе имеет смысл. Например, если разработчики видят фразу «Отменено на этапе заказа» дюжину раз в день, чтение ее не требует никакой мысли. Если вы замените эту фразу на C_CANCEL_STATUS, ваш код станет менее читаемым.

Возможно, вам просто нужен синтаксический сахар PL/SQL. Например, используя предопределенные коллекции и оператор member of может помочь упростить вещи:

declare 
    c_cancelled_statuses constant sys.dbms_debug_vc2coll := 
     sys.dbms_debug_vc2coll('Cancelled At Order Stage', 'Stopped at Billing Stage'); 
begin 
    if 'Cancelled At Order Stage' member of c_cancelled_statuses then 
     dbms_output.put_line('Cancelled!'); 
    end if; 
end; 
/

Все программисты понимают, что жесткое кодирование может быть плохим (правильно?). Жесткое кодирование может повредить ваш код, но, вероятно, его не убьет.

Но я видел несколько систем, полностью уничтоженных softcoding. Я знаю слишком много менеджеров, которые считают, что любая строка кода «жестко закодирована» и что вся логика должна храниться в таблице конфигурации. Многие ужасные, проприетарные языки программирования были построены из-за страха жесткого кодирования. Не чувствуйте себя слишком плохо из-за слишком жесткого кодирования.

источник

2015-02-13 23:24:17

+1. Мне это нравится. Я чувствую, что я слишком придирчив. Я думаю, что все возможно хорошо. Это читаемо и сразу понятно, и я думаю, что любые изменения, которые я сделаю, сделают это намного меньше. –

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

ответ

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