Here's one of those thoughts that I think to repost every few years. Many of us use variable naming conventions to carry various bits of information about what's in the variable/array. Like this format:
vtCity vlWindow Of course, no one uses that particular format as it's use will later condemn you to the pits of perdition. Instead, people are probably using: Module + Descriptor + Type Like Customer_City_t "Module" being a basic language concept missing from the 4D language. It's helpful to group resources into pseudo-modules to prevent pathological use of global data. But I digress. What I wanted to say again was something about type names: It can really improve the meaningfulness of a name if you expand your concept of 'type'. Instead of limiting ourselves to 4D's primitives, think of larger types. This can help in a few ways, the first being readability: $form_name_t $tFormName $form_name It's a name, of course it's text, what else would it be? Why tack _t on there? What does it add? It spends a couple of characters without adding any information. "Name" carries both the base type and it's type in the larger context of your code. The compiler can sort out types no matter what their name. 4D's automatic variable being a case in point: vRecNum It's text. Of course it is. And it almost squeezes maximum value out of the 8 character name limit ;-) Similar to form name, method name is an even better example: $error_method_name_t Okay, it's an error method. Well, we can validate method names - I'd prefer to think of it as $error_MethodName To the 4D Compiler, it's a string. That's it. But it isn't. Not any string will do, it has to be a string found in the list of project methods. Your code makes more sense when you see it that way. So, when the primitive type is obvious from context, why not use a 'type' abbreviation that tells you more? Here are three different longints: log_l log_l log_l Oh. What about log_docref log_hlist log_winref That's a lot more information for no real cost. I tend to use abbreviations like these as well as _name for internal names of stuff. Names are text in my universe, if you use longints or something - you're on your own. Oh, it's helpful to have a currency abbreviation if you apply standard rounding to reals-that-are-currency. I was reminded of all of this today as I'm doing some work with objects where know that the variable is an object tells me close to nothing. I've got an object that describes a 'recipient' of a callback from CALL WORKER or CALL FORM. So, it's type is "recipient" $subscriber_recipient $callback_recipient This is an object with a specific collection of attributes with rules. There's a method to create a recipient, to validate a recipient (make sure the window/method exists, etc.) Recipients can be passed around for various purposes. Right, back to your regular discussions.... ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
