Здравствуйте, remark, Вы писали:
R>MSVC имеет тенденцию генерировать как написано, т.е. не умничать. А попробуй для тех примеров, где ICC умничает, поставить целевой процессор Pentium4...
В данном случае наблюдалось для режимов P4 и Core2Duo (/QxP и /QxT)
R>
симметрично!
Здравствуйте, adontz, Вы писали:
A>Во-первых, else сразу виден по отступам, return — нет. Соответственно, понять что выполнится этот код или тот, сложнее. A>Во-вторых, неиспользование else приводит к потенциальной возможности внести баг при рефакторинге.
Ну, по моему опыту, те, кто пишут else после return кроме всего прочего плохо соблюдают отступы, комбинируют пробелы и табы, так что ничерта там по отступам не видно . Во вторых — return подствечивается как ключевое слово языка, и видно его достаточно хорошо. В третьих — рекомендуют минимизировать число return в тексте метода обычно, некоторые даже не стесняются добавлять лишний уровень вложенности чтоб остался только один return в конце (я правда это мнение не разделяю).
Про баг при рефакторинге можно поподробнее?
Здравствуйте, Aikin, Вы писали:
A>Твой же вариант понятен после небольшого обдумывания (0,5 сек, не более, но все же обдумывания) либо когда ты знаком с таким подходом.
В защиту варианта без else приведу еще один довод. return — ОЧЕНЬ опасный оператор, так как изменяет логику выполнения метода. После него не выполняется ничего. Так вот, так как этот оператор опасен — нужно делать так, чтобы он стал как более заметным. Когда мы делаем return, закрываем фигурную скобку и далее ставим пустую строку — этот return сразу становится более видимым. В случае же с else — опаратор else закрывает return от взгляда, и его в результате становится сложнее заметить. Важнее то у нас то, что у нас return, а не то, что у нас else
Здравствуйте, elmal, Вы писали:
E>Ну, по моему опыту, те, кто пишут else после return кроме всего прочего плохо соблюдают отступы, комбинируют пробелы и табы, так что ничерта там по отступам не видно .
Я работабю с включённым View Whitespace и в довесок регулярно CtrlK,Ctrl+D жму, так что мимо.
E>Во вторых — return подствечивается как ключевое слово языка, и видно его достаточно хорошо.
Ничего там не видно, пол-программы это ключевые слова.
E>В третьих — рекомендуют минимизировать число return в тексте метода обычно, некоторые даже не стесняются добавлять лишний уровень вложенности чтоб остался только один return в конце (я правда это мнение не разделяю).
Обычно это приводит к введению вспомогательных переменных и в целом ухудшает читаемость.
E>Про баг при рефакторинге можно поподробнее?
Когда нет else никто тебе не скажет "error CS0161: not all code paths return a value", потому что где-то внизу всегда есть return. Соответственно, забыть реализовать ветку очень просто.
Скажем, рефакторинг заключается в том, что теперь мы хотим вернуть только первые 50 символов строки. пример надуманный, но суть покажет.
if (data != null)
{
if (data.FirstValue.Length < 50)
{
return data.FirstValue;
}
// А вот это забыли написать
// return data.FirstValue.Substring(0, 50);
}
return string.Empty;
Получаем логическую ошибку. В моём варианте
if (data != null)
{
if (data.FirstValue.Length < 50)
{
return data.FirstValue;
}
// А вот это забыли написать
//else
//{
// return data.FirstValue.Substring(0, 50);
//}
}
else
{
return string.Empty;
}
Здравствуйте, adontz, Вы писали:
A>Я работабю с включённым View Whitespace и в довесок регулярно CtrlK,Ctrl+D жму, так что мимо.
Бывают такие заказчики, что жать такие кнопки низя . Так любят бренчеваться, что переформатировать код запрещено административно, бывает и такое .
A>Ничего там не видно, пол-программы это ключевые слова.
Я ответил в соседнюю ветку еще одну причину.
A>Обычно это приводит к введению вспомогательных переменных и в целом ухудшает читаемость.
Ну, с этим то я согласен, но лишний уровень вложенности ИМХО уменьшает читаемость еще больше.
A>Когда нет else никто тебе не скажет "error CS0161: not all code paths return a value", потому что где-то внизу всегда есть return. Соответственно, забыть реализовать ветку очень просто.
Ну, у меня например среда разработки до компиляции будет орать черти как, что у меня вообще код не правильный в случае, если забуду return . Ругнется ли компилятор не знаю, не проверял.
Ну, рефакторить тут надо совсем по другому . Поставив задачу уменьшить вложенность.
Здравствуйте, Legion13, Вы писали:
L>Наоборот, короче получается. "Если то-то, вернуть это." И все.
Если бы было "И все" не было бы о чем спорить. Но там не все, а пошла логика дальше.
Здравствуйте, elmal, Вы писали:
A>>Твой же вариант понятен после небольшого обдумывания (0,5 сек, не более, но все же обдумывания) либо когда ты знаком с таким подходом. E>В защиту варианта без else приведу еще один довод. return — ОЧЕНЬ опасный оператор, так как изменяет логику выполнения метода. После него не выполняется ничего.
Очень опасный Изменяет логику. elmal, тебе самому не смешно? Любая закорючка в коде (исключая коментариев) изменяет логику, после этого что, код не писать?
E>Так вот, так как этот оператор опасен — нужно делать так, чтобы он стал как более заметным. Когда мы делаем return, закрываем фигурную скобку и далее ставим пустую строку — этот return сразу становится более видимым. В случае же с else — опаратор else закрывает return от взгляда, и его в результате становится сложнее заметить. Важнее то у нас то, что у нас return, а не то, что у нас else
Ага, первый, вон, заметен, а второй уже нет? Я говорю вот о чем: раз оба варианта равнозначны (хотя бы логически), то их нужно одинаково выделять или не выделять.
Давайте доведем эту боязнь до абсолюта и потребуем единственный выход из функции:
string Foo(object a)
{
string result;
MyType data = a as MyType;
if (data == null)
{
result = string.Empty;
}
else
{
result = data.FirstValue;
}
return result;
}
Так лучше? Врядли.
Хотя этот прием имеет право на жизнь (особенно когда result является аккумулятором), но явно не в данном случае.
А вообще, делайте так как вам удобнее и удобнее вашим коллегам. Тут болше дело вкуса. Ибо и так, и так, и сяк правильно.
Здравствуйте, Aikin, Вы писали:
A>Очень опасный Изменяет логику. A>elmal, тебе самому не смешно? Любая закорючка в коде (исключая коментариев) изменяет логику, после этого что, код не писать?
Я имел ввиду, что этот оператор абсолютно сродни оператору goto, тем он и опасен. Выход с посощью return из двух циклов сразу и все такое — вполне нормальная практика, но, так как по сути return это тот же goto — крайне желательно, чтобы соответствующий оператор был хорошо заметен. При беглом просмотре программы я просто могу не сразу заметить этот return, в результате читать программу становится труднее.
Здравствуйте, elmal, Вы писали:
E>Ну, с этим то я согласен, но лишний уровень вложенности ИМХО уменьшает читаемость еще больше.
Тут дело вот в чем: он не лишний, а такой же как и у true-ветви if-а. Поэтому он ничего не уменьшает/усложняет.
Здравствуйте, Aikin, Вы писали:
E>>Ну, с этим то я согласен, но лишний уровень вложенности ИМХО уменьшает читаемость еще больше. A>Тут дело вот в чем: он не лишний, а такой же как и у true-ветви if-а. Поэтому он ничего не уменьшает/усложняет.
Чую такими темпами в священные войны перейдем скоро . Так вот — если убрать else, в результате не требуется делать дополнительный отступ, как результат — больше вероятность того, что строчка влезет в заданное количество символов.
Лишний не лишний. Можно уменьшить уровень вложенности хотя б для одной ветки — значит лишний . Нельзя — значит не лишний . На практике то, многие еще в ветвь else еще один if потом захотят запихнуть, а в тот if еще for и т.д . И в этой каше потом твоя совесть будет чиста только в том случае, если ты не сделал вообще ни одного лишнего уровня вложенности и написал все по фен шую .
Здравствуйте, adontz, Вы писали:
A>вот. Это существенно. Что тут сказать? Моё личное мнение, что 78 символов — устаревшее ограничение и wide мониторы рулят
Ну, я тоже поддерживаю такое мнение, и увеличил его до 120 (именно через столько символов показывает среда разработки вертикальную разделительную линию). Но в любом случае, число символов в строке должно быть ограниченно, 78 или 120 — не принципиально .
Здравствуйте, remark, Вы писали:
R>Зависит от того, какая ветвь вероятнее. Всё очень просто. Смотрим Intel® 64 and IA-32 Architectures Optimization Reference Manual:
R> — predict unconditional branches to be taken R> — predict indirect branches to be NOT taken R> — predict backward conditional branches to be taken R> — predict forward conditional branches to be NOT taken
А что, __builtin_expect/__assume и if(unlikely(p == null_ptr)) уже отменили?
Тем более, что в C++0y предполагается что-то вроде if [[ std::probably ]] (condition).
. Во вторых — return подствечивается как ключевое слово языка, и видно его достаточно хорошо. В третьих — рекомендуют минимизировать число return в тексте метода обычно, некоторые даже не стесняются добавлять лишний уровень вложенности чтоб остался только один return в конце (я правда это мнение не разделяю).
. Поставив задачу уменьшить вложенность.
