Здравствуйте, igna, Вы писали:
VD>>Это удобно при отладке. Ты видишь промежуточные значения без захода в функции.
I>Вот такое тоже удобно при отладке:
I>
I> var par1 = variable1.Method1(variable1A, variable1B);
I> if (DoSomethingUseful(par1)) {
I> . . .
I> }
I>
I>Но чаще пишут все же:
Чаще как раз пишут с заведением промежуточных переменных.
В общем, кури Рефакторинг Фаулера. Там есть объяснения многого из того, как делать не стоит. Про временные переменные там вроде тоже было. Только не помню, за них или против.
Здравствуйте, Lloyd, Вы писали:
L>В общем, кури Рефакторинг Фаулера. Там есть объяснения многого из того, как делать не стоит. Про временные переменные там вроде тоже было. Только не помню, за них или против.
Он написал, что "за", только если они являются поясняющими, но сам использует их редко.
Здравствуйте, igna, Вы писали:
I>Совет минимизировать область видимости переменной общеизвестен. Минимальная область видимости это область видимости неименованной переменной
I>
I> var par1 = variable1.Method1(variable1A, variable1B);
I> var par2 = variable2.Method2(variable2A, variable2B);
I> var par3 = variable3.Method3(variable3A, variable3B);
I> if (DoSomethingUseful(par1, par2, par3)) {
I> . . .
I> }
I>
Хм... А я почему-то всегда стараюсь чтобы в условиях циклов и условных операторов не было (по возможности) вызовов функций. То есть этот участок я бы переписал как
{
int par1 = var1.m1(v1a, v1b);
int par2 = var2.m1(v2a, v2b);
int par3 = var3.m1(v3a, v3b);
bool boSomethingUsefulOk = DoSomethingUseful(par1, par2, par3);
if (boSomethingUsefulOk){
// ...
}
}
И мне кажется любому читающему так гораздо понятней -- мы вводим дополнительную сущность, которая имеет смысл "всё ли в порядке". Представьте что пройдёт какое-то время и вам придётся в if заходить если DoSomethingUseful и при это DoSomethingUseful2. Тогда ваш вариант предполагает следующее расширение:
if (DoSomethingUseful(par1, par2, par3) && DoSomethingUseful2(par1, par2, par3)) {
не говоря уже о том, что вариант с внесением всего что можно в скобки условия порождает такие варианты как
for (int i = 0; i != lstrlenA(str); ++i){
//...
}
тогда как очевидно, что длину строки нужно вычислять вне цикла (если строка не изменяется внутри) или явным образом пересчитывать внутри, если изменяется.
Короче общая идея такая: фанатизм с ограничением области видимости ни к чему хорошему не приводит. Область должна быть наивозможно узкой, но не уже, чем требует здравый смысл, удобность чтения и формирование процедурной абстракции.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Это просто? За такое дублирование отстреливают. ExtractMethod!!!
I>Ты опять придираешься. Речь не о том, а о том, что вместо например:
I>
I> var par1 = variable1.Method1(variable1A, variable1B);
I> var par2 = variable2.Method2(variable2A, variable2B);
I> var par3 = variable3.Method3(variable3A, variable3B);
I> if (DoSomethingUseful(par1, par2, par3)) {
I> . . .
I> var par1a = callSomeFunctionWithALongName1();
I> var par2a = callSomeFunctionWithALongName2();
I> var par3a = callSomeFunctionWithALongName3();
I> if (DoSomethingUseful(par1a, par2a, par3a)) {
I> . . .
I> }
I> . . .
I> }
I>
I>По поводу твоих придирок: Даже в книгах, за которые авторы деньги получают, в примерах весьма нередко можно найти какие-либо не относящиеся к рассматриваемому вопросу недочеты. Уж для упрощения ли или от авторской лени ... А я и вовсе не пытаюсь ничего продавать, так что не обессудь, мои примеры для людей обладающих способностью мыслить абстрактно.
У меня есть замечательная привычка в таких сравнениях писать константу до (чтобы не нарваться на присваивание):
int iSomethingUsefulResult = DoSomethingUseful(par1, par2, par3);
if (0 == iSomethingUsefulResult){
// ...
}
}
Но делать такое в случае булевских переменных мне кажется избыточно. Аналогично в случае указателей. И там и там вобщемт всего два логических варианта -- TRUE/FALSE, либо NULL/NOT NULL и в обоих случаях if (pString) и соответственно if (!boFailed) вполне читабельны. Впрочем дело вкуса и ничего религиозного -- при соответствующих code guidelines я был бы согласен легко перестроится на явное сравнение.
Здравствуйте, igna, Вы писали:
I>Совет минимизировать область видимости переменной общеизвестен. Минимальная область видимости это область видимости неименованной переменной, тем не менее часто избегают писать так: I>и пишут так: I>
I> var par1 = variable1.Method1(variable1A, variable1B);
I> var par2 = variable2.Method2(variable2A, variable2B);
I> var par3 = variable3.Method3(variable3A, variable3B);
I> if (DoSomethingUseful(par1, par2, par3)) {
I> . . .
I> }
I>
А я пишу так:
var par1 = variable1.Method1(variable1A, variable1B);
{
var par2 = variable2.Method2(variable2A, variable2B);
var par3 = variable3.Method3(variable3A, variable3B);
if (DoSomethingUseful(par1, par2, par3)) {
. . .
}
}
DoSomethingAnotherUseful(par1);
И область видимости минимизируется, и отлаживать удобно.
Здравствуйте, igna, Вы писали:
I>Какая самодокументируемость повышается, если результат возвращаемый методом CreateTransglucator() помещается в переменную transglucator?
А если в переменную redTransglukator?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
I>>Какая самодокументируемость повышается, если результат возвращаемый методом CreateTransglucator() помещается в переменную transglucator?
AVK>А если в переменную redTransglukator?
Если вызовом CreateTransglucator(RED), то хрен редьки не слаще.
