Сообщение Re: Покритикуйте код от 09.02.2015 3:42
Изменено 09.02.2015 3:44 omgOnoz
Здравствуйте, CEMb, Вы писали:
CEM>Почитал соседнюю ветку, и вспомнилось...
CEM>Принцип создания функции инициализации:
![](/Forum/Images/maniac.gif)
CEM>чтоб понятнее, в чём суть, лучше так:
![](/Forum/Images/crash.gif)
CEM>Часто в примерах встречал код, который инициализировал некоторые члены класса один за другим, в случае ошибки делал деинициализацию уже готовых. В результате к хвосту функции число вызова деинициализаторов было велико. Ну и повторы кода на каждом условии.
CEM>Как вариант, люди использовали некую булеву переменную для понимания, что инициализации идут хорошо, каждая новая инициализация обкладывалась условием на эту переменную. В конце эта переменная проверялась, если false, то проверялись опять же все хендлы на валидность, и делалась деинициализация.
CEM>Мне кажется, мой код проще и нагляднее, быстро расширяется, можно не бояться забыть, что что-то пропустил.
CEM>Жду: критику, доработку, идеи
Сделать uninit / release — который ничего не делает, если ресурс не был выделен.
Если тебе так хочется JavaStyle — то пусть эксепшн кидают InitCommon / InitSome0 — а в catch вызываеться — UninitCommon() -> который вызовет m_two.UninitCommon() и т.п.
CEM>Почитал соседнюю ветку, и вспомнилось...
CEM>Принцип создания функции инициализации:
Скрытый текст | |
CEM>
CEM>у меня конкретно в коде были вызовы статических методов классов для инициализации общих данных, (через C:: ). | |
![](/Forum/Images/maniac.gif)
CEM>чтоб понятнее, в чём суть, лучше так:
Скрытый текст | |
CEM>
| |
![](/Forum/Images/crash.gif)
CEM>Часто в примерах встречал код, который инициализировал некоторые члены класса один за другим, в случае ошибки делал деинициализацию уже готовых. В результате к хвосту функции число вызова деинициализаторов было велико. Ну и повторы кода на каждом условии.
CEM>Как вариант, люди использовали некую булеву переменную для понимания, что инициализации идут хорошо, каждая новая инициализация обкладывалась условием на эту переменную. В конце эта переменная проверялась, если false, то проверялись опять же все хендлы на валидность, и делалась деинициализация.
CEM>Мне кажется, мой код проще и нагляднее, быстро расширяется, можно не бояться забыть, что что-то пропустил.
CEM>Жду: критику, доработку, идеи
Сделать uninit / release — который ничего не делает, если ресурс не был выделен.
Если тебе так хочется JavaStyle — то пусть эксепшн кидают InitCommon / InitSome0 — а в catch вызываеться — UninitCommon() -> который вызовет m_two.UninitCommon() и т.п.
BOOL CApp::InitCommon()
{
try
{
m_zero.InitCommon();
m_one.InitCommon();
m_two.InitCommon();
}
catch(int iExc)
{
UninitCommon();
return FALSE;
}
return TRUE;
}
void CApp::UninitCommon()
{
m_two.UninitCommon();
m_one.UninitCommon();
m_zero.UninitCommon();
}
Здравствуйте, CEMb, Вы писали:
CEM>Почитал соседнюю ветку, и вспомнилось...
CEM>Принцип создания функции инициализации:
![](/Forum/Images/maniac.gif)
CEM>чтоб понятнее, в чём суть, лучше так:
![](/Forum/Images/crash.gif)
CEM>Часто в примерах встречал код, который инициализировал некоторые члены класса один за другим, в случае ошибки делал деинициализацию уже готовых. В результате к хвосту функции число вызова деинициализаторов было велико. Ну и повторы кода на каждом условии.
CEM>Как вариант, люди использовали некую булеву переменную для понимания, что инициализации идут хорошо, каждая новая инициализация обкладывалась условием на эту переменную. В конце эта переменная проверялась, если false, то проверялись опять же все хендлы на валидность, и делалась деинициализация.
CEM>Мне кажется, мой код проще и нагляднее, быстро расширяется, можно не бояться забыть, что что-то пропустил.
CEM>Жду: критику, доработку, идеи
Сделать uninit / release — который ничего не делает, если ресурс не был выделен.
Если тебе так хочется JavaStyle — то пусть эксепшн кидают InitCommon / InitSome0 — а в catch вызываеться — UninitCommon() -> который вызовет m_two.UninitCommon() и т.п.
CEM>Почитал соседнюю ветку, и вспомнилось...
CEM>Принцип создания функции инициализации:
Скрытый текст | |
CEM>
CEM>у меня конкретно в коде были вызовы статических методов классов для инициализации общих данных, (через C:: ). | |
![](/Forum/Images/maniac.gif)
CEM>чтоб понятнее, в чём суть, лучше так:
Скрытый текст | |
CEM>
| |
![](/Forum/Images/crash.gif)
CEM>Часто в примерах встречал код, который инициализировал некоторые члены класса один за другим, в случае ошибки делал деинициализацию уже готовых. В результате к хвосту функции число вызова деинициализаторов было велико. Ну и повторы кода на каждом условии.
CEM>Как вариант, люди использовали некую булеву переменную для понимания, что инициализации идут хорошо, каждая новая инициализация обкладывалась условием на эту переменную. В конце эта переменная проверялась, если false, то проверялись опять же все хендлы на валидность, и делалась деинициализация.
CEM>Мне кажется, мой код проще и нагляднее, быстро расширяется, можно не бояться забыть, что что-то пропустил.
CEM>Жду: критику, доработку, идеи
Сделать uninit / release — который ничего не делает, если ресурс не был выделен.
Если тебе так хочется JavaStyle — то пусть эксепшн кидают InitCommon / InitSome0 — а в catch вызываеться — UninitCommon() -> который вызовет m_two.UninitCommon() и т.п.
BOOL CApp::InitCommon()
{
try
{
m_zero.InitCommon();
m_one.InitCommon();
m_two.InitCommon();
}
catch(ExpectedException ee)
{
UninitCommon();
return FALSE;
}
return TRUE;
}
void CApp::UninitCommon()
{
m_two.UninitCommon();
m_one.UninitCommon();
m_zero.UninitCommon();
}