Are those procedures used in the same app? Will the other developers have access to them or possibly have to modify them in the future? Aren't you 'going against the grain?' While your procedures may be more efficient, if all developers in-house except for you do it differently, then in essence, you are working in contradiction to a standard. Standards can be in writing (they should be) but they can also be in effect simply by standard practice. IMHO you may be asking for trouble Naomi. I don't recommend it. Many times in the past I have coded against my personal preferences in order to be in sync with the other developers. Unless it is something that the other developers don't care one way or the other about - but that doesn't appear to be the case.


>I'm the only one supporter here and the rest of the developers hate them. There is 0 chance of falling into the variables vs. field traps since practically every developer follows naming convention. So, it's more of a habit and for me it's a lost battle. But at least I want to continue using them in my procedures despite the others' attitudes.
>
>>This is an example of something I would definitely discuss with the boss...
>>The only reasons I can think of for not changing it when you see it:
>>1. The variable used in its current format is used throughout the app
>>2. The developer has worked on the app for years and knows the variables currently used thoughout the app by heart
>>3. There is a guidance or set of standards in place that contradict it
>>
>>*Also, any documentation on the variables would need to be updated when the variable name is changed.
>>
>>>>>>m. is hated by your coleagues??? Hate them:)
>>>>>>Cetin
>>>>>
>>>>>Do you mean you hate m. too? Oh, no <g>
>>>>
>>>>No, I mean I hate those who hates m.
>>>>Cetin
>>>
>>>It's really funny. In the program that used by several developers my colleague put **** PLEASE DO NOT PLACE "m."s *** at the top and removed m. even from my procedures <g>