Уместен ли return в void функциях? Как лучше else-if-else или множественные return`ы?

Question

[Даниил Демидко]

Что бы было понятнее, почему я спрашиваю: мне 16, и не у кого спросить насчет стиля написания кода.
Сейчас я пишу небольшое приложение для себя (C#). И вот недавно озадачился вопросом-
Есть void функция (хоть и не суть важно, но скажу- работает с GUI представлением файловой системы), как лучше оформить блоки кода- используя блоки if-else-if, или используя блоки с return; ?
Покажу на примере:

//StackPanel - из WPF, для вывода файлов директории на экран
void FilesView(String Name, StackPanel FilesPanel)
{
   FileInfo а=new FileInfo(Name);
   if(а.Exists)
   {
       //код открывает файл
   }
   else//Блок else что бы не брать лишний раз память под b
   {
        DirecoryInfo b=new DirectoryInfo(Name);
        if(b.Exists)
        {
          //код выводит файлы и папки в FilesPanel
        }
   }
}

или так

void FilesView(String Name)
{
   FileInfo а=new FileInfo(Name);
   if(а.Exists)
   {
       //код
       return;
   }
   DirecoryInfo b=new DirectoryInfo(Name);
    if(b.Exists)
   {
       //код
   }
}

Я вижу что вариант с return не растягивает "полотно" блоков if else, но стоит ли так делать постоянно?
Как будет лучше?
Как будет лучше для стиля оформления? Как правильнее? Кто нибудь может разъяснить?

В общем вопрос таков: Уместен ли return или множественные return`ы в void функциях?

Comments

[Даниил Демидко]

Как я понял- большое полотно из if-else-if - зло?

[Алексей Уколов]

Daniro_San: это не зло, просто один из индикаторов того, что код можно улучшить. Бывает так, что этот индикатор выдает ложное срабатывание. Но чаще, конечно, функцию можно улучшить отрефакторив.

[AtomKrieg]

"//Блок else что бы не брать лишний раз память под b" без else память и не выделиться если вы не дойдете до инструкции DirecoryInfo b=...

Answer 1

[Алексей Уколов]

Стандарт кодирования, это такая вещь, из-за которой любят поломать копья. Он - как поэзия, сложно измерить его вклад в вашу жизнь. На мой взгляд, самое правильное - сформулировать свой стандарт (он может на 100% совпадать с каким-то уже существующим), обосновать его самому себе и жить спокойно. Стандарт можно пересматривать по необходимости время от времени.

Скорее всего, вам нужно разбить эту функцию на две (или больше). Без полного кода точно не сказать.

Существует мнение, что чем меньше уровней вложенности в коде (второй вариант), тем лучше. Но это только мнение и вы сами должны понимать, когда его принимать в расчет, а когда нет.
Разумеется, это понимание нужно выработать, но сделать это можно только практикуясь. Так что, пишите код, читайте книги, читайте чужой код и постепенно выработаете свой стандарт (Хотя, почитать что-нибудь на эту тему, конечно, совсем не вредно - https://refactoring.guru)

Answer 2

[Дмитрий Ковальский]

Лично мне не очень понятно что вы хотите сделать этой функцией. Если получить список файлов в директории или еще где-то. То тут все проще. Такая функция не должна делать вывод в gui, только возврат элементов для показа. А вот метод для работы с gui уже void. он должен получить список, отрисовать его и закрыться

Comments

[Даниил Демидко]

Именно работа с GUI- просто в примере кода написал не все аргументы- если файл, то открывает, если директория- то отрисовывает директорию.

[Дмитрий Ковальский]

Даниил Демидко: Просто для начала различайте "извлечение данных" и "вывод данных". Это разные функции и они не должны быть описаны в одном методе. Посмотрите какие данные и в каком формате вам нужны для интерфейса и напишите метод, который их возвращает в данном формате.

[Даниил Демидко]

Дмитрий Ковальский: У меня есть функция (Например GetFileButton) возвращающих кнопку отвечающую за GUI представление файла.
Функция которую я использовал в примере получает список файлов и директорий в папке используя класс DirectoryInfo, получает GUI представление от GetFileButton и закрепляет на FilesPanel. Все.
Это неправильно?

Answer 3

[Dark_Scorpion]

У вас заметил всего 1 if+else. Значит правильно использовать его.
Если много вложенности if+else много, надо использовать switch+case. Если вложенность состоит из стандартных проверок, по именам файлов , то цикл.
При стандартных проблемах вложенности, return почти не используется. Это дурной тон.

Answer 4

[Владислав Танков]

Как правило return уместен в случае, если выполнение алгоритма идёт по ненормальному сценарию, использование его приводит к меньшей вложенности кода, однако так же приводит и к возможному повторению общего для всех сценариев исполнения алгоритма кода выхода (например отключение логирования перед return (справиться с этим помогут, к примеру, аспекты)).
Использование return уместно в коде без сложных условий на выход.
В некоторых случаях от использования повторяющихся if поможет избавиться паттерн состояние (не в данном случае)
Про красивый код можно почитать тут или же прочесть совершенный код Макконела. Так же есть смысл посмотреть руководства по стилю в каких-то больших проектах на том же github (они обычно лежат в разделе wiki), или, возможно, таковое есть на сайте msdn.

Answer 5

[Дмитрий Макаров]

Портянки if-else не любит никто. Это раз. Некоторые не любят множественные return`ы. Это два.

Лично для меня удобен вариант с return`ами.

Если сравнивать, с большим количеством вложенных if-else`ов, код становится разреженным - сложно глазами все удержать. А с return`ами более компактно получается.

Кроме того, если, например, метод запускается с некоторой вырожденной комбинацией параметров и часть кода получается незадействованной, то сразу видно, что в таких то условиях в методе никаких больше действий выполнятся не будет, а не искать где-то там в конце закрывающие скобочки и разбираться относится ли оператор в межскобочном пространстве недалеко от конца метода к данной области видимости.

Множественные return`ы не любят потому, что вроде как одна точка входа и одна точка выхода - это хорошо. Что, мол, бывают случаи, когда независимо от условий, перед выходом из метода нужно будет выполнить какое-нибудь общее действие, типа освобождения ресурсов. Но, это бывает далеко не всегда. И слепо следовать принципу: "одна точка входа/одна - выхода" не стоит.

В общем, ответ на ваш вопрос: "Пиши читабельный код и DRY (Don`t Repeat Yourself)"

Answer 6

[Александр Дубина]

как вариант часто встречаю, что лучше вместо ифов использовать дикшинари - читабельность повышается в разы а размер кода уменьшается. Работает по скорости (если у вас не миллионы условий) - одинаково