Coding Style Question

realJSOP

I just got a new job doing (gak!) VB, and I'm going through the existing code base trying to get my bearings. I've run across something that I'm not sure I agree with. They have a class which has a property that contains about 60 lines of code, and this code runs through some financial calculations to come up with a value that is returned. I guess one good thing is that no methods or data is accessed that exists outside this class. I've always been of the opinion that a property shouldn't perform anything more than simple get/set functionality, and extra processing should be handled in a method. Indeed, I've been bitten by this in the past, so I take extreme steps to avoid it now. What do you guys think?

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

Luc Pattyn

I haven't done such things myself, and I wouldn't do it. Most often a getter simply returns a private data member's value, whereas a setter may be more complex, as it may have to update the internal state of the entire object, not just the one corresponding data member. A calculation deserves a method. However IMO it is just a matter of style, I know of no technical reason to prefer a method over a getter property. And that would be the same in most .NET languages... :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

Rozis

I disagree, I don't have any problem with code for a property. I think of properties of a class as a 'logical' view to it, that is more or less independent of the actual implementation. Where I have to agree with you is that this raises the question if a property is 'physical' or 'logical'. Rozis

Not Active

I would agree; keep the property simple. You are dealing with VB, I'm sure you will find much worse coding.

I know the language. I've read a book. - _Madmatt

dan sh

John Simmons / outlaw programmer wrote:

property that contains about 60 lines of code...

...must be changed to method. That is what I would have done. Apart from little bit code like increment/decrement or any conversion/casting if needed, I never write anything in properties.

50-50-90 rule: Anytime I have a 50-50 chance of getting something right, there's a 90% probability I'll get it wrong...!!

realJSOP

I don't either - generally, but this one calls methods in the class, and as far as I'm concerned, that's a no-no because it could throw an exception. IMHO, setting/getting properties should NOT be able to throw exceptions because they should always contain valid data.

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

Lost User

Luc Pattyn wrote:

I know of no technical reason to prefer a method over a getter property.

Not a technical, but empirical; a method would imply an action of some sort, to retrieve a value. A property would imply that there's a value to be read.

I are Troll :suss:

Luc Pattyn

Yes, I agree, to me a getter typically returns the value of an internal variable, however there isn't a hard border line for me. I would not mind getting property "Area" for a Rectangle object (even if setting Area wouldn't make sense); and I would try and avoid database accesses in a property. Having a method name with a verb in there should indicate real actions, whereas property names are supposed to be nouns, without verb part. :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

T2102

You want interface as lean as possible. If you need additional functions than they should be private functions in VB or static functions in your source files in C/C++. 60 lines is not that large of a function.

vtchris peterson

I agree with what's been said here, in summary: get should do be limited to: minimal computation involving readily available data set should do be limited to: minimal computation involved to transfer data to a readily available store and any relevant event handler notification. There's nothing worse than expanding this in Visual Studio and having to wait for 5 minutes while it evaluates a bunch of properties that you likely don't care about!