This says it all... https://www.itworld.com/article/2823759/enterprise-software/124383-Arg-The-9-hardest-things-programmers-have-to-do.html#slide10 <https://www.martinfowler.com/bliki/TwoHardThings.html>
Dani Beaubien Open Road Development > On Dec 16, 2018, at 3:24 PM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > 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 < > 4d_tech@lists.4d.com> wrote: > >> On Sun, Dec 16, 2018 at 10:15 PM B.Bippus via 4D_Tech < >> 4d_tech@lists.4d.com> >> 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:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
