Coding standard-function returning multiple values

I hope I'm not opening up a standards war here, but what's the best way to handle a function that needs to return multiple values? One group here holds for declaring public variables to hold those values while another holds for including them as ByRef arguments.

In the specific case it's a function that, given partial data, determines whether or not a record containing that data exists in the database. It needs to return information that it found either 0, 1, or more than 1 records containing the information-but if it finds only one record then it also needs to return the ID of that record.

Thanks.

Since the functionality is local to that task and not the application as a whole, byref is better for you then a global declaration IMO.

Both ways are perfectly exceptable. It all depends on the situation and specific needs.

In this case, I would agree with sevenhalo.

Provide a scenerio of a different type and I might go with the public variables.

Another alternative would be to wrap the function in a class and have it only return the number. The ID, if needed, could be a property of the class. This is kind of a bludgeoning approach.

Yet another alternative would be to have the function return a strucutre that contains both values.

Oh yeah, of the two you mentioned, I strongly prefer the ByRef method for the reasons Hack mentioned.

I probably would have opted for returning an array from the function....but that's just me.

-tg

In certain cases I would create a structure.

Neither structure nor array is really appropriate for the actual code-although I could probably make them work. But I do favor the ByRef approach-if there's a problem with a variable (usually casting) then I like to have the variable declared in the same procedure as that in which it's used.

On the other hand we already have several objects declared globally simply because they're used everywhere.

Thanks.

Why would the structure not be appropriate? Simple disposable object to deal with, keeps everything encapsulated, and you don't have to use a side effect. I'm not thrilled with functions that alter their arguments, though I have found reason to use them often enough.

Quote:

---

On the other hand we already have several objects declared globally simply because they're used everywhere.

---

That's typically the main ingredient for disaster. The fact that it's "used everywhere" is going to be real fun to trace when it was "changed somewhere."

That's my main argument against public variables, 7, but it doesn't really apply to either the existing public variables nor the proposed one which, once set, will remain unchanged until we move on to another record. Theoretically that makes public variables acceptable-or at least tolerable. In practice the existence of 'correct' public variables seems to invariably encourage their proliferation. Gawd, those things seem to breed like rabbits!

Obviously my feeling is to have no public variables. Even though I consider some to be OK, it seems like once you let the camel stick its nose inside the tent there's no stopping it-first thing you know the camel has the whole tent & you're out in the cold.

Thanks.

That's not the kind of "something changed" he meant.... he meant an actual change to the code... where the value then gets jacked because "something" in the code changed.

-tg

I have to say that I've never run into that situation. Are you saying that people write code that inadvertently changes the values of variables that they don't reference in their code?

I could see how someone could carelessly 'reuse' the same name for a local variable, thus confusing people-and that confusion could then lead someone to alter the value while out of scope, leading to an inadvertent change in the public variable-but I'd be extremely upset with someone who failed to follow the shop naming standards that way.

Other than that I just don't see what 7 is aiming at. Possibly my problem-our apps all deal with the same databases so we don't have problems where a variable 'could mean this or could mean that'.

They may or may not use it involuntarily. It's a small chance scenario, but it's deffinitely one that happens. It usually happens with common names to like sqlConn or sqlCmd or strIN, ect ect. People use them and forget to declare them. Since the IDE sees them globally, it doesn't give them an error so they assume that they've already declared it. In actuallity, it's a global value that they're modifying and you (and the rest of your code) weren't planning on it.

I subscribe to the philosophy of never giving anything a greater scope than absolutely necessary - it limits these sorts of problems.

As for the function, either reference/pointer arguments or returning a structure would be preferable. It depends on the type of data represented.

That explains why we don't see it here, 7, we require very descriptive names for anything greater than local scope. E.g. rather than SQLConn it would be DBNameConn. Right now, local means procedure. We're new enough to VB.Net that nobody's used block-level variables yet. I can see those creating problems as we do allow 'generic' variable names within a procedure.

I subscribe to a similar philosophy, pen. The only difference is I don't adhere to the 'absolutely' necessary part. We do require justification for giving something greater scope than local, but sometimes I feel that the justification is a little weak. ("It's easier that way" isn't, in my opinion, sufficient justification. But there are times when I've been overruled. I may be the lead programmer here, but I'm not the boss.)

Thanks, all. We're going with a ByRef parameter. Possibly not the best decision, but better than going with a global variable in my opinion.

Very fair :)