Page 1 of 1

Returning different types from a function - best practice?

Posted: Mon Jul 21, 2008 5:59 am
by Skittlewidth
Hello all, long time no speak... I'm fed up with the micro$oft .net forums... my questions seem to be too deep for the "No question too stupid" forum and too generic for their specific topic forums and the moderators often reject my posts! Plus they're so much slower to respond than you guys. Still, doing this job is paying my morgage so I hope you'll forgive my "betrayal" of the open source community and help me with this question - its a theory question, but I've put it in Misc cos I'm doing VB.net...

I have a function that helps to validate a web form. I'm trying to separate the validation logic from the actual manipulation of the form controls as far as possible.

A form field contains the maximum number of users a company account can have. This is editable by admin even after a company has started to add users, therefore if this field is updated, the number cannot be less than the number of users that already exists.

If the validation fails, then this function needs to return the minimum number a particular form field can have so that the field can be corrected, therefore I initially set the return type to "integer".

However if the validation passes, what value can I return to signify this?

Option 1) I could set it to "-1" since logically a company cannot have "-1" users, however I am loathe to do this because in several scenarios elsewhere in the application "-1" signifies false (e.g. where a value has not been selected in a select box)

Option 2) I could set the return type to "object" and return an integer on failure and true on pass, but it seems ugly to define the return type so loosely.

Option 3) I could alternatively return only true or false on pass or failure and then call a second function to return the corrected value to the form but since the first function has to run a stored procedure to count the number of licences and check it against the form field value, it seems to be very inefficient to make a second function query the database again to return the number when the first function already had the number in the first place.

Option 4) The validation functions are in a separate class, should I create a class property that can receive the number of licences from validation function 1, and write a getter function so I can retrieve this number if function 1 returns false? Should I make sure that the getter cannot be called if the validation function was not called before it?

Sorry if I'm rambling, or the answer seems obvious to you - I've just returned from camp (as a long suffering youth leader) and as you might imagine I'm rather sleep deprived...

Any constructive opinions are appreciated.

Re: Returning different types from a function - best practice?

Posted: Wed Aug 06, 2008 1:46 am
by RobertGonzalez
What is the core purpose of the function?

Re: Returning different types from a function - best practice?

Posted: Wed Aug 06, 2008 3:42 pm
by alex.barylski
C++ support's method overloading where you can have multiple methods in the same class so long as they differ in at least function signature or return type.

Althoguh when I first discovered this I thought it was the coolest thing since sliced bread years later I have to question that as a best practice. Think about it, code should simple and easy to read and for this to happen we require clarity. The number one problem with method overloading is it introduces a cognitive ambiguity. That is to say, while a computer can technically distinguish between:

Code: Select all

 
createUser($fname, $lname, $age = 30);
createUser($object);
createUser($array)
 
As a client developer using that class I see a few problems:

1. To many options leads to difficulty in selection. Sure alternatives are nice but sometimes we go over board. I walk into a subway and I can't decide what I want. If they gave me one sandwich I'd have no choice and be done with it. Choice is good when it comes to arts and culture but technically...choice can sometimes slow us down.

2. If we just stuck with the first one or second or third...we have the benefit of consistency. If it's one thing I can't stand and find confusing as hell when entering a new code base is the lack of consistency. I can tell you that I am pedantic about convention consistency, techniques, etc. I find it leads to more bug free software and is far easier to come back to months later and just pick up where you left off.

So I say, while options are nice they are also a PITA sometimes...so method overloading is bad practice although it looks neat...just like multiple inheritence did when it was first discovered.