I agree with Peter. Object names need to convey what their purpose is, at best, and be as unambiguous as possible at least. The size of the method has a lot to do with how ambiguous a name might be. I have no qualms about using $i as an index counter in a method where there is only one loop or it's only a few lines long. It's really simple to rename variables if the method starts to go long.
I've seen plenty of code with long var names, type appended, that are just as difficult to read as code with abstruse names and no system. Personally I think confusing naming schemes arise when the overall purpose of the code is lost or poorly defined. A little time making sure we know what we are doing might be more productive than typing long variables names. Remember what they say, there are only 2 hard things in writing code: naming things, clearing the cache and the off-by-one problem. On Sun, Dec 16, 2018 at 2:08 PM Peter Bozek via 4D_Tech < [email protected]> wrote: > On Sun, Dec 16, 2018 at 10:15 PM B.Bippus via 4D_Tech < > [email protected]> > wrote: > > > Begin each variable name with a character to specify what type it is: > > · String: s > > · Text: t > > · Boolean: y > > > > To add the Variable Type to the Variablename is a big help. I started > many > > years ago to prepend the Type. And I am using the "4D Pop Marco > > Declaration" to automatically declare every variable. (I have a complete > > Regex Setup for prepending the Type if someone need it). > > > > But in the last days I am thinking if it would have been better to append > > the Type: For example: $t_Name vs. $Name_t. > > So if you are starting with a variable-name convention: Think about it > > first. > > > > And because of the Object-Tag names are case-sensitive, it makes sense to > > have a convention for the Object-Tag names too. I use: every Name-Part > > starts with a uppercase character and the rest is lowercase. Example > Tags : > > "Last_Changed" , "Simple_Tag". > > > > My variable naming conventions : > > C_LONGINT($l_WinRef) > > C_OBJECT($o_parameter_3) > > C_REAL($r_Amount) > > C_TEXT($t_Customer_Code) > > C_BOOLEAN($b_ok) > > C_DATE($d_Budgets_End_Date) > > C_OBJECT($o_Parameter) > > C_POINTER($p_Table) > > C_Blob($bl_Var) > > > > ARRAY LONGINT($al_Budgets_Code;0) > > ARRAY REAL($ar_Sum_of_Trades;0) > > > > I will offer a contrarian view: Some time ago, I was using the same > notation (Camel one, but that is detail) but now I decided against it. > > I maintain several databases for a long time, so so I have a lot of > variables with 's' prefix, what is now text. This is not a big problem, I > can understand that 's' and 't' means the same, but it still disturb me a > bit. But with integer prefix i had a dilemma, as integer arrays still > exists and need to be used with integer fields, so I rather redeclared and > renamed all integer variables and arrays with 'l', but are still unsure > when I see 'ai' prefix in some old code - did I forgot to redeclare and > rename it, or is it still an integer (and should it be changed to longint?) > > Second, as I often work with code written by different developer, mix of > various styles lead to not really well readable code. And I hate variable > names like $day_D (or, even better, $d_D) or $index_L etc. It provides no > information and makes the code ugly and unreadable. (Besides, does not 4D > now show variable type as cursor hoover above it?) > > I now try to provide clear and readable variable names, without prefixes or > postfixes. This means I would have > C_LONGINT($winRef) > C_REAL($amount) > C_TEXT($customerCode) > > I still use prefix when the type of variable is different from what the > name would suggest, but I prefer, when possible, names like $tablePtr; > $tableNo and $tableName to $p_table, $l_table and $t_table. I would still > use > C_BOOLEAN($bOK) but > C_LONGINT($OK) > > I would still use > C_OBJECT($oParameter2) > but would try avoid such names. > > Such names lead to readable code - like > For($index;1;$size) > $sum:=$sum+$amount > ... > works well with other notations, and are easier to write. > > -- > > Peter Bozek > -- Kirk Brooks San Francisco, CA ======================= *We go vote - they go home* ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
