quite interesting read, thanks. The value of sensible naming never shows more strongly when you have to work with OPC (Other Peoples Code) and find generic variables like S_1 or AR1 that are used in changing roles throughout the code and are an incredible pain to debug, or even replace…
Concerning the descriptor, I have found it more useful to have that up front, spearated by underscore: $t_myText $al_myLongArray o_processObject etc. Why? 3 reasons: - when typing and you need a specific local text variable you already have, just type the prefix and the editor will show you all text variables you already have. - I can easily check for compiler typing errors by searching (for example) all C_LONGINT in compiler declarations where the variable does not start with l_ and, much more import as I am lazy: I have a macro and method that automatically declares all my locals in a method and puts the block on top. Easier to recognize the type if you just need to match a starting pattern… Cheers Alex > Am 24.02.2017 um 04:29 schrieb David Adams via 4D_Tech <4d_tech@lists.4d.com>: > > 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:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** ********************************************************************** 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:4d_tech-unsubscr...@lists.4d.com **********************************************************************
