23:36
Untitled [360]
О том, почему плохо применять одну и ту же переменную для двух разных задач.
Была одна процедура (процедура в смысле "логическое действие, которое должна выполнять программа", а не в смысле "функция в терминах языка программирования, которая не возвращает значения") и она имела, допустим, три режима:
#define MODE1 1
#define MODE2 2
#define MODE3 3
А у каждого из режимов было два подрежима:
#define MODE1A 1
#define MODE2A 2
#define MODE3A 3
#define MODE1B 4
#define MODE2B 5
#define MODE3B 6
И была переменная, которая хранила ОБА этих режима.
int nMode;
СНАЧАЛА там хранился общий режим и процедура работала с его использованием. Но, на определённом этапе (которой пришлось долго вычислять, т.к. процедура длинная) та же переменная начинала хранить уже ПОДРЕЖИМ. При этом диагностику затрудняло то, что числовые значения констант частично совпадали.
Не надо так.
P.S. Предвижу вопрос "Почему не сделали сразу просто хранение подрежимов, а на режимы бы просто не забили?". На самом деле режимов не три, а больше. А число подрежимов у каждого режима -- своё. На определённом этапе ветвление осуществляется по коду режима, а по коду подрежима -- потом. Поэтому разделение на "режим" и "подрежим" логично. Что нелогично -- так это одна переменная и под то и под другое. И что очень плохо -- что замена режима на подрежим происходила при вызове определённой функции ВНУТРИ неё, при этом замена производилась по ссылке:
void non_suspicious_name(int a, int b, int &mode)
{
mode=0;//...или что-нибудь ещё
}
//в другой функции
non_suspicious_name(val1,val2,nMode);
// теперь тут уже не режим, а подрежим
Это аргумент в пользу того, чтобы не использовать ссылки, а только указатели.
Была одна процедура (процедура в смысле "логическое действие, которое должна выполнять программа", а не в смысле "функция в терминах языка программирования, которая не возвращает значения") и она имела, допустим, три режима:
#define MODE1 1
#define MODE2 2
#define MODE3 3
А у каждого из режимов было два подрежима:
#define MODE1A 1
#define MODE2A 2
#define MODE3A 3
#define MODE1B 4
#define MODE2B 5
#define MODE3B 6
И была переменная, которая хранила ОБА этих режима.
int nMode;
СНАЧАЛА там хранился общий режим и процедура работала с его использованием. Но, на определённом этапе (которой пришлось долго вычислять, т.к. процедура длинная) та же переменная начинала хранить уже ПОДРЕЖИМ. При этом диагностику затрудняло то, что числовые значения констант частично совпадали.
Не надо так.
P.S. Предвижу вопрос "Почему не сделали сразу просто хранение подрежимов, а на режимы бы просто не забили?". На самом деле режимов не три, а больше. А число подрежимов у каждого режима -- своё. На определённом этапе ветвление осуществляется по коду режима, а по коду подрежима -- потом. Поэтому разделение на "режим" и "подрежим" логично. Что нелогично -- так это одна переменная и под то и под другое. И что очень плохо -- что замена режима на подрежим происходила при вызове определённой функции ВНУТРИ неё, при этом замена производилась по ссылке:
void non_suspicious_name(int a, int b, int &mode)
{
mode=0;//...или что-нибудь ещё
}
//в другой функции
non_suspicious_name(val1,val2,nMode);
// теперь тут уже не режим, а подрежим
Это аргумент в пользу того, чтобы не использовать ссылки, а только указатели.
