Actually, re-reading your earlier post, you're being a complete hypocrite. You said
"inside the same class use i = me._intID :)" Not even a should - simply prescribing to others how they should code. That is far worse (by your definition) than me saying Should! On Thu, Dec 17, 2009 at 12:48 PM, Jamie Fraser <[email protected]>wrote: > No, I understand exactly what you mean, but I feel that is the way that > people SHOULD do it, hence my use of the word. > > I didn't find your earlier comments either funny or productive regarding my > ability (or you perceiving my "lack of" ability), and I like to think I've > been fairly successful so far in my career as a Developer, and if *I* think > something should be done in a particular way, I'm happy to tell this to > others. Whether they do this or not is entirely up to them. However, this is > becoming self-perpetuating, as you think I *shouldn't* tell people what I > think they *should* do. > > Let's just agree to disagree, and try not to throw any "jokes" around > later. > > > On Thu, Dec 17, 2009 at 12:25 PM, Processor Devil < > [email protected]> wrote: > >> again and again... Yes, many open source projects uses that... and many >> open source project are also nothing more but just spaghetti code (try to >> search for SpectateSwamp Desktop Search, you will laugh for sure), but... >> why the hell do I need some less skilled programmer to change encryption key >> and IV vector properties in my class when there is function which does both >> and it works as it should? Sometimes you just need to change MORE than just >> one variable to make the code works, do you want end-programmer to do it one >> by one and let him make a mistake or omit something or you will give him >> just function that will change it internally and all for sure? >> >> P.S. about the Open Source projects... so if they do it then it is the >> only way? All I wanted you to do next time was not to use word SHOULD, is it >> hard to understand? >> >> >> 2009/12/17 Jamie Fraser <[email protected]> >> >>> >>> >>> On Thu, Dec 17, 2009 at 11:38 AM, Processor Devil < >>> [email protected]> wrote: >>> >>>> well, in read-only variables you don't need to specify the Set part at >>>> all... >>>> another thing I was about also was that specifying logic inside the >>>> property is not a really good practice (it is always better to create some >>>> private method and call it from inside, it saves time and it is better for >>>> reusability as well). >>>> >>> >>> How do you set the property then? By accessing the field directly? I >>> don't like that. If you get using a property, you should set using a >>> property. >>> >>> And there is NOTHING wrong with having some logic within the property - >>> take a look through the source code of any major Open Source project and see >>> how they do it. >>> >>> >>> >>>> And the exact thing I wanted to hear was this: "In general, I find it >>>> good practice to use Get Properties (where they exist) as a default". Yes, >>>> you find it a good practice, but it is not general good practice, you >>>> should >>>> NOT say anyone that he SHOULD use it. It is also the reason why this thread >>>> started... Bunch of programmers who uses this practice told him that he >>>> SHOULD do it their way and he got confused... It is your good practice, it >>>> is not my good practice, but I am not going to force you to do it my way >>>> ;-) >>>> >>>> Sorry if I do look like being upset, the reason is that I am upset, I >>>> have to attend LiveMeeting which is 2 hours in length and sound doesn't >>>> work >>>> as it should... >>>> >>>> 2009/12/17 Jamie Fraser <[email protected]> >>>> >>>>> >>>>> >>>>> Yes, of course if property has some logic which checks the set value or >>>>>> count the get value from something then yes, you should use the property, >>>>>> but why to use it when it contains only eg get {return this.value} ? and >>>>>> one >>>>>> more thing about your message: >>>>>> >>>>> >>>>> In general, I find it good practice to use Get Properties (where they >>>>> exist) as a default. They might only say >>>>> >>>>> return _abc; >>>>> >>>>> but then they might say >>>>> >>>>> if(x || y) { _abc = _service.Refresh(); } else { _abc = >>>>> service.Load(_id); } >>>>> return _abc; >>>>> >>>>> And they also might *change* from example 1 to example 2. If you >>>>> consistently use the Get Property, if the logic changes, your code will >>>>> still work. Remember - another developer might change the logic contained >>>>> in >>>>> the property but NOT check the the rest of the code for where it is used. >>>>> >>>>> So, elsewhere in the class, if you say >>>>> >>>>> int a = _abc; >>>>> >>>>> Then your code breaks. >>>>> >>>>> But if you say >>>>> >>>>> int a = PropertyABC; >>>>> >>>>> Then your code continues working. It is a safety net - win/win, if you >>>>> will. If the property only returns _abc, then the compiler will inline >>>>> this >>>>> to int a = _abc anyway, so there is no performance hit. >>>>> >>>>> >>>>> >>>>>> -If the property is read-only, then there is a reason for this (i.e. >>>>>> logic already exists internally to set the value of the underlying field) >>>>>> and that logic is? Sorry, but I don't quite understand that, coding >>>>>> classes always means to create some its own logic and how does look a >>>>>> logic >>>>>> to set the variable? Maybe this.variable = value? Oh no, sry, you can't, >>>>>> you >>>>>> must use property for this... but property is read-only? Damn, so there >>>>>> already MUST be some logic that sets it... >>>>>> --that was test of some irony, don't get it personally ;-) >>>>>> >>>>>> >>>>> I don't really get what you mean here. >>>>> >>>>> In the case of a read-only variable, you want to prevent *external* >>>>> classes from changing the value of the field. Therefore, you do something >>>>> like >>>>> >>>>> public string Name >>>>> { >>>>> get >>>>> { >>>>> return _name; >>>>> } >>>>> private set >>>>> { >>>>> _name = value; >>>>> } >>>>> } >>>>> >>>>> And you use the property as normal. >>>>> >>>> >>>> >>> >> >
