Is Multiple Exit points in a method wrong [modified]
-
Hi 1) Someone told me a function should have only one exit point - why is this? 2) Is it bad practice to use the input to the function directly. In example below, I compare intInput to a constant (10). Should I first equate intInput to a local variable and then use a local variable in the comparison. Just seems like extra code to use anothe variable? 3) As opposed to using 'Return True' or 'Return False' is it better to use the function name - E.g. 'Test = False' Private Function Test(byVal intInput as Integer) as Boolean If intInput >10 then Return True Else Return False End If End Function -- modified at 5:15 Saturday 5th May, 2007
-
Hi 1) Someone told me a function should have only one exit point - why is this? 2) Is it bad practice to use the input to the function directly. In example below, I compare intInput to a constant (10). Should I first equate intInput to a local variable and then use a local variable in the comparison. Just seems like extra code to use anothe variable? 3) As opposed to using 'Return True' or 'Return False' is it better to use the function name - E.g. 'Test = False' Private Function Test(byVal intInput as Integer) as Boolean If intInput >10 then Return True Else Return False End If End Function -- modified at 5:15 Saturday 5th May, 2007
friend.. Answer to question 1 : i'm not sure of it. Answer to question 2 : its a good practise, if u use a temporary variable inside functions. this keeps the original value safe and secure. dont hesitate to write some more code for this, bcoz its usefull when it comes to large programs.. Answer to question 3 : there are no difference between these two, but it is good to use 'Test = False', becoz thats the correct syntax while writing a function. still it is not mandatory. the code will work...
-
friend.. Answer to question 1 : i'm not sure of it. Answer to question 2 : its a good practise, if u use a temporary variable inside functions. this keeps the original value safe and secure. dont hesitate to write some more code for this, bcoz its usefull when it comes to large programs.. Answer to question 3 : there are no difference between these two, but it is good to use 'Test = False', becoz thats the correct syntax while writing a function. still it is not mandatory. the code will work...
Thanks :)
-
Hi 1) Someone told me a function should have only one exit point - why is this? 2) Is it bad practice to use the input to the function directly. In example below, I compare intInput to a constant (10). Should I first equate intInput to a local variable and then use a local variable in the comparison. Just seems like extra code to use anothe variable? 3) As opposed to using 'Return True' or 'Return False' is it better to use the function name - E.g. 'Test = False' Private Function Test(byVal intInput as Integer) as Boolean If intInput >10 then Return True Else Return False End If End Function -- modified at 5:15 Saturday 5th May, 2007
RichardBerry wrote:
- Someone told me a function should have only one exit point - why is this?
It is an ideal but I think most developers are not religious about it. The main reason is maintainability, especially with longer, more elaborate functions. OTOH, in OO code, and in procedural code for that matter, functions should not be too long. For the example you supply it doesn't matter much. Though it is more concise to write Return intInput > 10
RichardBerry wrote:
- Is it bad practice to use the input to the function directly. In example below, I compare intInput to a constant (10). Should I first equate intInput to a local variable and then use a local variable in the comparison. Just seems like extra code to use anothe variable?
No, it's not bad practice if all you're doing is effectively "reading" the input variable, as in your example. It is bad practice to modify the input variable and use the modification for subsequent processing. In this case you should take a copy.
RichardBerry wrote:
- As opposed to using 'Return True' or 'Return False' is it better to use the function name - E.g. 'Test = False'
This is VB .NET right? Using Return is the recommended way. Using the function name is retained only for backward compatibility.
Kevin
-
Hi 1) Someone told me a function should have only one exit point - why is this? 2) Is it bad practice to use the input to the function directly. In example below, I compare intInput to a constant (10). Should I first equate intInput to a local variable and then use a local variable in the comparison. Just seems like extra code to use anothe variable? 3) As opposed to using 'Return True' or 'Return False' is it better to use the function name - E.g. 'Test = False' Private Function Test(byVal intInput as Integer) as Boolean If intInput >10 then Return True Else Return False End If End Function -- modified at 5:15 Saturday 5th May, 2007
RichardBerry wrote:
- Someone told me a function should have only one exit point - why is this?
A big reason is code maintainability. One way in, one way out. If the code has to be modified, you don't have to hunt down all the exit points in a function to make sure it's returning a good value.
RichardBerry wrote:
- Is it bad practice to use the input to the function directly. In example below, I compare intInput to a constant (10).
Yes, it is, but not for the reason you think. The first thing a function should normally do, is validate the incomming data. This may require multiple tests on multiple parameters. It may also be helpful to put the validated data in local variables so you know that you're using validated data in the rest of the function code.
RichardBerry wrote:
- As opposed to using 'Return True' or 'Return False' is it better to use the function name - E.g. 'Test = False'
No, it's not. Quite the opposite. In some languages, including older versions of VB, you had to assign the return value to the function name. It's far more readable and maintainable to use a Return statement. The "assign to function name" method is still in there for backwards compatibility. I wish it would just go away...
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
RichardBerry wrote:
- Someone told me a function should have only one exit point - why is this?
A big reason is code maintainability. One way in, one way out. If the code has to be modified, you don't have to hunt down all the exit points in a function to make sure it's returning a good value.
RichardBerry wrote:
- Is it bad practice to use the input to the function directly. In example below, I compare intInput to a constant (10).
Yes, it is, but not for the reason you think. The first thing a function should normally do, is validate the incomming data. This may require multiple tests on multiple parameters. It may also be helpful to put the validated data in local variables so you know that you're using validated data in the rest of the function code.
RichardBerry wrote:
- As opposed to using 'Return True' or 'Return False' is it better to use the function name - E.g. 'Test = False'
No, it's not. Quite the opposite. In some languages, including older versions of VB, you had to assign the return value to the function name. It's far more readable and maintainable to use a Return statement. The "assign to function name" method is still in there for backwards compatibility. I wish it would just go away...
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Dave Kreskowiak wrote:
One way in, one way out. If the code has to be modified, you don't have to hunt down all the exit points in a function to make sure it's returning a good value.
Excellent point. In this case, it is easiest to have a temporary boolean variable such as
resultand plug it in with the single return statement... -
Dave Kreskowiak wrote:
One way in, one way out. If the code has to be modified, you don't have to hunt down all the exit points in a function to make sure it's returning a good value.
Excellent point. In this case, it is easiest to have a temporary boolean variable such as
resultand plug it in with the single return statement...Paul Conrad wrote:
In this case, it is easiest to have a temporary boolean variable such as result and plug it in with the single return statement...
I use this technique quite regularly.
Kevin
-
Paul Conrad wrote:
In this case, it is easiest to have a temporary boolean variable such as result and plug it in with the single return statement...
I use this technique quite regularly.
Kevin
Kevin McFarlane wrote:
I use this technique quite regularly.
And it pretty much works out for the best too :-D
-
RichardBerry wrote:
- Someone told me a function should have only one exit point - why is this?
A big reason is code maintainability. One way in, one way out. If the code has to be modified, you don't have to hunt down all the exit points in a function to make sure it's returning a good value.
RichardBerry wrote:
- Is it bad practice to use the input to the function directly. In example below, I compare intInput to a constant (10).
Yes, it is, but not for the reason you think. The first thing a function should normally do, is validate the incomming data. This may require multiple tests on multiple parameters. It may also be helpful to put the validated data in local variables so you know that you're using validated data in the rest of the function code.
RichardBerry wrote:
- As opposed to using 'Return True' or 'Return False' is it better to use the function name - E.g. 'Test = False'
No, it's not. Quite the opposite. In some languages, including older versions of VB, you had to assign the return value to the function name. It's far more readable and maintainable to use a Return statement. The "assign to function name" method is still in there for backwards compatibility. I wish it would just go away...
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Many thanks! By the way - Is it normal to thank someone for their reply on a forum- I feel it's just plain good manners, but on the other hand it clutters the forum...
-
Many thanks! By the way - Is it normal to thank someone for their reply on a forum- I feel it's just plain good manners, but on the other hand it clutters the forum...
RichardBerry wrote:
By the way - Is it normal to thank someone for their reply on a forum
Sure it is! It happens so rarely, that it doesn't really clutter up anything. :-D No problem.
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007