Open fredrikekre opened 2 months ago
For try
I think the rules would be:
finally
branch with return
this will override any other return so it is misleading to add return
in any other branch (perhaps Runic should even remove existing ones?)else
it can always have return
except it is misleading to add if 1. or if the try
block has a return
.try
block can have it if there is no else
and if not 1.
Currently Runic will format something e.g.
into
However, looking at some real world code examples of this it seems that about 50% of the time returning whatever value comes out of the
if
is not intended and addingreturn
after the block is a better "fix". e.g.and around 50% or the time it is better to insert the returns inside the branches, e.g.
Some potential changes to the current setup:
return
in any branch recurse and add returns in the branches instead of putting thereturn
in front of the whole block. The question would then be if Runic should also add an explicitelse
branch when no such branch exist, e.g.would become
return
in any branch, make sure there is a return in all branches.The same discussion applies to
try
, but fortry
it can actually improve readability a bit too since it isn't obvious what the possible return values are in e.g.so making it explicit is a good idea, e.g.