Is return appropriate in void functions? Which is better else-if-else or multiple returns?

Question

C++ / C#

To make it clearer why I'm asking: I'm 16 and there's no one to ask about coding style.
Right now I'm writing a small application for myself (C#). And recently I was puzzled by the question
- There is a void function (although it’s not important, but I’ll say - it works with a GUI representation of the file system), how best to arrange code blocks - using if-else-if blocks, or using blocks with return; ?
I'll show you with an example:

//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
        }
   }
}

or so

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

I see that the return option does not stretch the "canvas" of if else blocks, but is it worth doing this all the time?
How will be better?
What would be best for styling? What is more correct? Can anyone explain?
In general, the question is: Is it appropriate to return or multiple returns in void functions?

Answer 1

The coding standard is the kind of thing that people like to break spears over. He is like poetry, it is difficult to measure his contribution to your life. In my opinion, the most correct thing is to formulate your own standard (it can 100% coincide with some existing one), justify it to yourself and live in peace. The standard may be revised as necessary from time to time.
Most likely, you need to split this function into two (or more). Can't say for sure without the full code.
There is an opinion that the fewer levels of nesting in the code (the second option), the better. But this is only an opinion and you yourself must understand when to take it into account and when not.
Of course, this understanding needs to be developed, but this can only be done by practice. So, write code, read books, read other people's code and gradually develop your own standard (Although, of course, reading something on this topic is not at all harmful - https://refactoring.guru)

Answer 2

Personally, it's not very clear to me what you want to do with this function. If you get a list of files in a directory or somewhere else. Everything is easier here. Such a function should not output to the gui, only return elements to display. But the method for working with gui is already void. it should get the list, draw it and close

Answer 3

You noticed only 1 if+else. So it is correct to use it.
If there is a lot of if+else nesting, switch+case should be used. If the nesting consists of standard checks, by filenames, then loop.
With standard nesting problems, return is almost never used. This is bad tone.

Answer 4

As a rule, return is appropriate if the algorithm is executed according to an abnormal scenario, using it leads to less code nesting, however, it also leads to a possible repetition of the exit code common to all execution scenarios (for example, disabling logging before return (will help to cope with this , for example, aspects)).
The use of return is appropriate in code without complex exit conditions.
In some cases, the state pattern will help to get rid of the use of repeated if (not in this case) You
can read about beautiful code hereor read McConnell's perfect code. It also makes sense to look at style guides in some large projects on the same github (they are usually in the wiki section), or perhaps there is one on the msdn site.

Answer 5

Nobody likes if-else footcloths. This time. Some people don't like multiple returns. This is two.
For me personally, the return option is convenient.
Compared to a lot of nested if-else `s, the code becomes sparse - it's hard to keep your eyes on everything. And with return `ami it turns out more compactly.
In addition, if, for example, the method is launched with some degenerate combination of parameters and part of the code turns out to be unused, then it is immediately clear that under such conditions, no more actions will be performed in the method, and not look for closing brackets somewhere at the end and to understand whether the operator in the inter-parenthesis space near the end of the method belongs to the given scope.
They don't like multiple returns because it seems like one entry point and one exit point is good. That, they say, there are cases when, regardless of the conditions, before exiting the method, it will be necessary to perform some general action, such as releasing resources. But, this does not always happen. And blindly follow the principle: "one entry point / one exit point" is not worth it.
In general, the answer to your question is: "Write readable code and DRY (Don`t Repeat Yourself)"

Answer 6

In such an example, a cycle would be appropriate.

Answer 7

as an option, I often see that it is better to use dikshinari instead of ifs - readability increases many times and the code size decreases. Works for speed (unless you have millions of conditions) - the same