Debate: ref vs. return

[Nerseus]

I love watching people get fired up about things that aren't necessarily important, but still fun to have opinions about... with that in mind:

 

Do you, or does your company, have a "standard" for using ref/ByRef vs ONLY allowing methods to return values?

 

I've seen 3 typical scenarios:

1. [ref/ByRef is a strict no-no] A method should ONLY return a single value (the return type), ref/ByRef parameters used to return values is a no-no (maybe Ok to pass strings, for performance). If multiple returns are needed, us a custom object, hashtable, etc.

 

2. [ref/ByRef is perfectly acceptable] A method should return values using ref/ByRef whenever needed.

 

3. [ref/ByRef is mostly a no-no, but occasionally Ok] A method should almost never use ref/ByRef but it's Ok in certain, VERY limited situations.

 

-ner

 

PS This comes to mind as a previous boss of mine is now looking to come work for my company as an "underling". He was/is extremely opinionated and once tied up a developer meeting for *hours* trying to get everyone convinced of something that he later flip-flopped on and then flip-flopped again a few months after that.

[Joe Mamma]

I often use

int MyFunction(ref object aObject)

if MyFunction needs to manipulate aObject properties. . . the return is an error code depending on success

or

int MyFunction(out object aObject)

if aObject is null, int is the error code

 

the later usually implies a Class Factory method though which would be

 

object MyFactoryFunction()

[Arch4ngel]

I never modify an object inside a function unless it's sent by value. I always return 1 data. And if I need to return more data.... well.. build a struct, make a hash table....

 

For me... data should be returned. Never modified. What if your data is set to null ? You'll have to search for hours inside if it's this function who set an null somewhere.

 

So.... I'm going for the first option.

[Denaes]

I never modify an object inside a function unless it's sent by value. I always return 1 data. And if I need to return more data.... well.. build a struct, make a hash table....

 

For me... data should be returned. Never modified. What if your data is set to null ? You'll have to search for hours inside if it's this function who set an null somewhere.

 

So.... I'm going for the first option.

Personally I do returns mostly.

 

Nothing against byRef, I just do returns. Chances are if I'm using a group of data I create a struct to hold all of the data. It just seems to make sense and is easier to handle.

 

Is there a performance gain for byRef over structs that you'd notice? I think byRef might be cleaner if you're super organized, which I'm not always :)

[PlausiblyDamp]

If you are returning a null or setting a parameter to null you will still have a null value being passed around.

 

I personally tend towards option 3 - I avoid modifying refernces in a function an prefer to return a new object. I often find that in cases where I'm passing by reference and modifying the object the code can be refactored into a method of the original class.

The cases where I do use references are often in either static methods, when their use makes the code cleaner or for the odd performance issue where creating and returning a temporary object may be undesirable.

[Joe Mamma]

You know I thought about this, PD is right. I don't often use the ref keyword on passed parameters, as most of the time the properties are being changed on a reference type, which means they are mutable. i never change the object reference itself in a method.

 

I change the props and return an error code.

 

There are certain times that I use the 'out' modifier, but looking at my code it is always on a value type.

 

Its funny, but I don't really consider these things when programming - it just comes out that way.

[ThePentiumGuy]

I rarely use Ref.

A function like:

Add2Numbers(a,b,Result)

wouldn't make sense

 

but something like

 

Result = Add2Numbers(a,b) 'just an example :), obviously you wouldn't create a function for that.

 

Functions are more useful as well. For example if in the function you decide to... i dunno, instantiate 200 classes (just.. some random example),

and you don't feel like typing that in

 

Using a return type, you'd have to specify

Add2Numbers(1,2, Result) something like that, and oyu'd have to declare 'Result'.

 

Using functions:

Add2Numbers(1,2).. there you go, you dont even have to have somethign to the left of the equal sign, and now your function instantiates the 200 classes <REALLY bad example, but i hope you know what i mean :)>

 

So using functions, its not necessary declare the extra variable if you don't want the return type (thus using it as a Sub)

 

The Pentium Guy