| Subject | Re: field 'value' |
| From | Lee Grant <camilee@nospam.comcast.net> |
| Date | Thu, 21 Apr 2022 01:47:13 -0400 |
| Newsgroups | dbase.getting-started |
On 4/20/2022 6:22 PM, Charlie wrote: > I have a field named value. could someone confirm whether that is a legal field name in dbase? I have a feeling it isn't as there is some funky stuff going on. If you're going to insist on using that as a field name, then it's best that you use it with a context in the name. For instance, 'initValue' or 'initVal' or some such way to disguise the keyword, but also to self document what the heck you're doing, though I can think of a dozen different ways to name a field. 'initVal' or 'initValue' would be a great name for a variable that initializes a field's or entryfield's value, but for field names themselves, I usually use the purpose/context to name my fields or the table/app they belong to. For instance, I have a Vendor Master database. I use 'vmname' for the field for the name of the business. When I create my forms, now I have a field name that I can tack on references to the objects in my form that pertain to that field. For instance, for the title of the entryfield that the value of that field will go in, I'll name 'VMNAME_TL" for a TextLabel object that I'll put the text of "Name:" in, and then I name the entryfield that the field will actuallY appear in, 'VMNAME_EF" for an entryfield object. My field names are short, to the point, usually non-reserved, and they work well minimizing the object names that they attach to when I use the object names as abbreviations of their names. You have to constantly self document, that's the only way to avoid running headlong into a reserved word, and it's a lot more recognizable months down the road when you have to look at the code and fields again or have to make changes to them. Lee | |